@inf-monkeys-tech/monkeys-cli 0.10.6 → 0.11.1

package/skills/monkeys/references/data-perspective.md

@@ -1,45 +1,50 @@
 # Data 视角路由
 
-CLI 只提供确定性的 `--perspective kernel|studio` 断言和固定语义命令；路由策略由本 Skill 执行。现有 Server 的统一 Data 接口按当前 Session 是否具有 Kernel Scope 分流，CLI 不发送自定义视角 Header，也不能把同一个 Kernel Session 强制降权为 Studio。不得使用 `auto`，不得直接构造 `x-monkeys-data-perspective` Header。
+Data 查询视角由 CLI 根据经过认证的 Session 能力统一解析，Skill 不得自行模拟路由或手工重试。`--perspective` 只接受 `studio|kernel`；省略该参数表示使用 CLI 的自动策略，不得传 `auto`，也不得构造 `x-monkeys-data-perspective` Header。
 
-Team 与 Data Perspective 分开处理：Kernel 是租户内管理视角，Kernel 全局读取默认不传 `--team`；只有用户明确要求 Team 筛选时才传。Field、View、Feature Value、Advanced Asset Search 和 Asset Export 等需要下游数据资源 Team 时，使用用户或部署所有者已确认的 `--resource-team`；CLI 通过 `resourceLocator.source=explicit-flag` 报告，它不会改变 `teamMode=none`，不得描述成 Kernel 查询作用域。Ontology owner Team 与 data resource Team 可以不同，CLI 不会自动推导。Studio 的 Team 表示前台工作空间上下文。Session 的 `currentTeamId` 只是当前登录状态，不能据此宣称 Kernel 查询属于该 Team。
+## 决策合同
 
-## 决策顺序
+1. 用户明确要求 Studio/前台：传 `--perspective studio`，只查 Studio。即使 Session 同时具有 Kernel 权限，也不得升级到 Kernel；Studio 空结果或 404 直接返回。
+2. 用户明确要求 Kernel/后台/管理视角：传 `--perspective kernel`，直接查 Kernel。权限不足时报告 `DATA_KERNEL_PERMISSION_REQUIRED`，不得降级到 Studio。
+3. 用户未指定视角：省略 `--perspective`。
+   - Session 有 Studio 权限时先查 Studio。
+   - Studio 返回确定性的空集合，或精确 GET 资源返回 404，并且 Session 同时有 Kernel 权限时，CLI 最多自动升级一次到 Kernel。
+   - Session 只有 Kernel 权限时直接查 Kernel。
+   - 401/403、认证过期、网络错误、5xx、合同/响应不兼容、校验失败及其他不确定错误均不得触发升级。
+4. 写操作不会因失败或结果形态自动重放到另一个视角。治理命令和 `visible|creatable|all` 等固定语义入口仍受命令自身声明的可用视角约束；不支持所选视角时报告 `DATA_PERSPECTIVE_UNAVAILABLE`，不得换用 Raw API 伪造等价能力。
 
-1. 用户明确要求 Studio/前台视角：不得先尝试 Kernel。先用 `auth status` 确认 Session：
-   - 从用户明确输入或 `session.currentTeamId` 确认 Studio Team；使用 Session Team 时必须说明结果受该 Team 与前台权限限制。
-   - 固定 Studio 入口（例如 `data ontology list --scope visible|creatable`）可直接使用 `--perspective studio`。
-   - 其他统一 Data 命令只有在 `session.surfaces.kernel=false` 时才能使用 `--perspective studio`。
-   - 若当前 Session 具有 Kernel Scope，必须告诉用户现有 Server 无法将该 Session 强制切到 Studio，并要求用户选择无 Kernel 权限的账户/Profile；不得假装已经切换。
-2. 用户明确要求 Kernel/后台/管理视角：使用 `--perspective kernel`；全局读取不传 `--team`，用户明确要求某 Team 时才把 `--team` 作为筛选条件；命令需要资源定位时传已确认的 `--resource-team`，未知时先在聊天中说明并请求，不得猜测；权限不足时报告错误，不得降级。
-3. 用户未指定视角：每个任务最多运行一次 `monkeys auth status --profile <Profile> --output json` 检查能力。
-   - `session.surfaces.kernel=true`：使用 `--perspective kernel`；全局读取默认不传 `--team`。
-   - 当前身份没有 Kernel Surface，但命令有 Studio 等价能力：必须先在聊天中明确告诉用户“当前账户没有 Kernel 管理权限，本次将使用 Studio 视角；结果受前台可见性和权限限制。”，再使用 `--perspective studio`。
-   - 当前身份没有 Kernel Surface，且命令没有 Studio 等价能力：停止并报告需要 Kernel 权限。
+这套合同与 Lark CLI 的身份解析原则一致：显式选择优先于默认选择，命令声明支持的身份范围，最终解析结果进入结构化输出；Monkeys 额外只为确定性的只读空结果提供 Studio 到 Kernel 的一次升级。
 
-最终答复必须引用 CLI 返回的 `effectivePerspective` 与 `teamMode`；存在 `effectiveTeamId` 时同时报告。存在 `resourceLocator` 时说明该 Team 仅用于 Ontology 子资源定位、没有把 Kernel 全局结果收窄为 Team 筛选。若 CLI 只返回 `perspectiveSource=legacy-unverified`，必须明确说明实际视角未经确认。使用 Studio 时必须说明结果受前台 Team、可见性与权限过滤；不得把 Studio 空结果解释为 Kernel 中也不存在。
+## 输出与审计
 
-## 能力边界
+最终答复必须引用 CLI 返回的 `effectivePerspective`，并同时检查：
 
-- Session 路由、Kernel 与 Studio 均有实现：View、Asset、Tag、Tag Group、Field List/Ensure、Feature Value。实际分支由 Session Kernel Scope 决定。
-- 固定 Studio 语义：`data ontology list --scope visible|creatable`。
-- 固定 Kernel 语义：`data ontology list --scope all`、`data ontology get/create/update/import`、`data asset import-jsonl` 及其 `status/cancel`、`data field get/update` 和其他命令明确标记的 Kernel 专有治理操作。
-- Skill 默认发现 Ontology 时，Kernel 路径使用 `data ontology list --scope all --perspective kernel` 且不传 Team；Studio 路径使用 `data ontology list --scope visible --perspective studio --team <Team ID>`。
-- Kernel Field List/Get、View Tree/Rows、Feature Value、Feature 附件、Advanced Asset Search 和 Asset Export 使用独立 `--resource-team`，不手工补 `--team`。`DATA_RESOURCE_TEAM_REQUIRED`、`DATA_TEAM_ROLE_CONFLICT` 或 `DATA_RESOURCE_TEAM_NOT_APPLICABLE` 时停止并在聊天中报告；不尝试 owner Team、Team `0`、Session Team、Raw API 或空结果重试。
+- `requestedPerspective`：`studio`、`kernel` 或省略参数产生的 `auto`；
+- `effectivePerspective`：实际返回结果的视角；
+- `perspectiveSource`：`explicit`、`fixed-route` 或 `studio-first`；
+- `perspectiveResolution.attempts`：按顺序记录 `studio|kernel` 和 `success|empty|not_found`；
+- `perspectiveResolution.fallbackReason`：只有实际升级时才出现，为 `studio_empty` 或 `studio_not_found`；
+- `teamMode`、可选的 `effectiveTeamId` 与 `resourceLocator`。
+
+使用 Studio 返回结果时，说明结果受前台 Team、可见性与权限过滤。发生自动升级时，明确说明 Studio 的确定性空结果/精确资源不存在，以及最终数据来自 Kernel。没有 `fallbackReason` 时，不得宣称发生过升级。
+
+## Team 与资源定位
 
-## 受控降级
+Team 与 Data Perspective 分开处理：Kernel 是租户内管理视角，Kernel 全局读取默认不传 `--team`；只有用户明确要求 Team 筛选时才传。Studio 的 Team 表示前台 Team 上下文。
 
-优先在业务命令前通过 `auth status` 选择视角，避免先发一次 Kernel 业务请求。只有以下条件全部满足，Skill 才能把一次失败的 Kernel 尝试改为 Studio：
+Field、View、Feature Value、Advanced Asset Search 和 Asset Export 等 Kernel 子资源读取可能需要 `--resource-team`。它只接受用户或权威资源元数据已确认的数据资源 Team，不得从 Ontology owner Team、Session Team、空结果或 404 猜测。自动模式下可以预先传已确认的 `--resource-team`：Studio 尝试不会把它当作 Team 上下文；如果升级到 Kernel，CLI 才把它用于资源定位。CLI 通过 `resourceLocator.source=explicit-flag` 报告该定位，它不会把 `teamMode=none` 改成 Team 筛选，不得描述成 Kernel 查询作用域。
 
-- 用户没有明确要求 Kernel；
-- 错误为 `DATA_KERNEL_PERMISSION_REQUIRED`；
-- `safeDetails.requestState=not_sent`；
-- 同一语义命令具有 Studio 等价能力；
-- 保持同一 Profile、Deployment、Tenant、Ontology 和精确目标；Kernel 全局查询不得凭 Session Team 补造筛选，切换 Studio 前必须确认 Team 并明确告知作用域收窄；
-- 执行 Studio 命令前已在聊天中告知用户。
+`DATA_RESOURCE_TEAM_REQUIRED`、`DATA_TEAM_ROLE_CONFLICT` 或 `DATA_RESOURCE_TEAM_NOT_APPLICABLE` 时停止并报告；不得猜 Team `0`、切换为 Raw API 或继续盲试。
 
-每个任务最多发生一次 Perspective 降级。空结果、404、认证过期、网络错误、5xx、合同或响应不兼容、`sent`、`result_unknown` 都不得触发 Perspective 降级。Perspective 降级与语义命令到 Raw API 的受控降级是两套独立机制，不得混用 `fallbackEligible`。
+## Team 0 共享/系统分区
 
-`DATA_STUDIO_SESSION_REQUIRED` 表示当前 Kernel Session 会被统一接口路由到 Kernel，无法满足明确的 Studio 要求。停止并要求无 Kernel Scope 的账户/Profile，或改用固定 Studio 入口；不得改走 Raw API 伪造成功。
+Team `0` 是保留的共享/系统数据分区，不表示“所有 Team”。只有用户明确要求共享/系统数据，或权威资源元数据确认目标位于 Team `0` 时，才能使用它：直接选择 Team `0` 的 Ontology/Asset 分区时传 `--team 0`；Kernel 子资源定位时传 `--resource-team 0`。
 
-`DATA_PERSPECTIVE_SESSION_INCOMPATIBLE` 表示 CLI 无法从认证 Session 确认实际能力。停止并报告认证合同问题，不得根据 Profile 名称猜测视角。
+Team `0` 的 Ontology 可以作为共享 Schema 被其他 Team 复用，因此 `Ontology.teamId=0` 不自动证明其 Asset 或 data resource Team 也是 `0`。Studio/Public 路径中的 Team `0` 数据通常按共享发布数据只读使用，写权限仍完全以服务端授权为准。
+
+## 能力边界
+
+- 双视角查询：View、Asset、Tag、Tag Group、Field List/Get、Feature Value 等统一 Data 读取。
+- 固定 Studio 语义：`data ontology list --scope visible|creatable`。
+- 固定 Kernel 语义：`data ontology list --scope all`、`data ontology get/create/update/import`、`data asset import-jsonl` 及其 `status/cancel`，以及其他命令明确标记的 Kernel 专有治理操作。
+- Cursor 会绑定查询上下文并记录实际视角；Studio 首次升级到 Kernel 后，下一页直接延续 Kernel，不重新把 Kernel page token 发给 Studio。

package/skills/monkeys/references/data-read.md

@@ -14,21 +14,33 @@
 
 ## 流程
 
-1. 先按 Data 视角路由选择 `data ontology list --scope all --perspective kernel` 或 `data ontology list --scope visible --perspective studio --team <Team ID>`，解析明确的 Ontology。
-2. Kernel 全局读取默认不传 `--team`；只有用户明确要求某 Team 且命令支持筛选时才传。Field、View、Feature Value、Feature 附件和 Advanced Asset Search 需要后端资源 Team 时传已确认的 `--resource-team <数据 Team>`；不得从 Ontology owner `teamId`、Session 或空结果猜测。Studio 后续命令同时传明确的 `--team`、`--ontology <Ontology ID>` 和同一 `--perspective`，不传 `--resource-team`。
-3. 检查输出中的 `effectivePerspective`、`teamMode`、可选的 `effectiveTeamId` 和 `resourceLocator`；`teamMode=none` 表示 CLI 未施加 Team 上下文/筛选。`resourceLocator.source=explicit-flag` 和 `resourceLocator.teamId` 只说明后端分区定位，不得补造用户筛选。CLI 返回 `DATA_RESOURCE_TEAM_REQUIRED` 时在聊天中请求已确认的数据资源 Team，不得尝试 `0`。
-4. 用户要求“列出/查看某个 View 的数据”时，Kernel 默认使用 `monkeys data view rows --ontology <Ontology ID> --view <View ID> --resource-team <数据 Team> --limit 20 --perspective kernel --profile <Profile> --output json`；Studio 改用 `--team` 且不传 `--resource-team`。不要要求用户额外指定“完整列”，也不要先用紧凑 `data asset list` 代替。
+1. 用户明确要求 Kernel 时用 `data ontology list --scope all --perspective kernel`；明确要求 Studio 时用 `data ontology list --scope visible --perspective studio --team <Team ID>`。`visible|creatable|all` 是固定语义入口，不在它们之间自动改写。目标 Ontology 已知、用户未指定视角时，后续双视角查询省略 `--perspective`，由 CLI 执行 Studio-first。
+2. Kernel 全局读取默认不传 `--team`；只有用户明确要求某 Team 且命令支持筛选时才传。Field、View、Feature Value、Feature 附件和 Advanced Asset Search 需要后端资源 Team 时传已确认的 `--resource-team <数据 Team>`；不得从 Ontology owner `teamId`、Session 或空结果猜测。已确认目标位于共享/系统数据分区时，直接分区查询传 `--team 0`，子资源定位传 `--resource-team 0`。明确 Studio 时传 `--team` 且不传 `--resource-team`；自动模式可携带已确认的 `--resource-team` 供 Kernel 升级后定位，Studio 尝试不会把它当作 Team 上下文。
+3. 检查输出中的 `requestedPerspective`、`effectivePerspective`、`perspectiveResolution`、`teamMode`、可选的 `effectiveTeamId` 和 `resourceLocator`。`teamMode=none` 表示 CLI 未施加 Team 上下文/筛选；`resourceLocator` 只说明后端分区定位。`perspectiveResolution.fallbackReason` 为 `studio_empty|studio_not_found` 时，说明 Studio 已确定为空/不存在且最终结果来自 Kernel；其他错误不得由 Skill 手工换视角重试。CLI 返回 `DATA_RESOURCE_TEAM_REQUIRED` 时请求已确认的数据资源 Team；不得把 `0` 当默认兜底。
+4. 用户要求“列出/查看某个 View 的数据”且未指定视角时，使用 `monkeys data view rows --ontology <Ontology ID> --view <View ID> --resource-team <已确认的数据 Team> --limit 20 --profile <Profile> --output json`；CLI 会把复合查询整体固定在一个视角，必要时从头用 Kernel 重查，避免混合两侧数据。明确 Studio 时改用 `--team` 且不传 `--resource-team`；明确 Kernel 时补 `--perspective kernel`。不要要求用户额外指定“完整列”，也不要先用紧凑 `data asset list` 代替。
 5. View 类型为 `filter` 且已经配置 Tag/Field 规则时，继续使用 `data view rows`，由 CLI 按当前部署合同解析 `allOf`、`anyOf`、`noneOf` 与启用的字段规则。临时按 Ontology 全局 Feature 的结构化值筛选时，读取[Ontology Feature 结构化检索](ontology-feature-search.md)，使用 `data asset search --expression-json/--expression-file`；其他临时条件仍以命令 Help 为准。筛选失败或结果为空时先核对上下文、View 类型和规则，禁止通过 `data view convert-to-container` 兜底。
 6. 依据返回的有序 `columns` 和 `rows` 在聊天中展示完整 Markdown 表格。列较多时按列分成多个表格，每个表都保留 Asset ID 和名称用于关联；不得静默省略列。附件单元格只显示“可下载”和数量，不显示 URL。
 7. 只有用户明确要求简略列表、资源元数据或低上下文投影时，才使用 `data asset list --view <View ID>`。默认单页有界；只有用户确实需要时扩大范围。
 8. 抽样使用 `data asset sample` 的有界样本，不自行无限翻页后随机。
-9. 只复用同一 Context、Data Perspective、Team 模式、Data 合同、Ontology、View 和查询生成的 Cursor；游标不匹配时重新查询。
-10. 用户需要读取、查看或保存 Asset 封面图片/媒体时，使用 `monkeys data asset media download <Asset ID> --ontology <Ontology ID> --out <本地路径> --perspective <kernel|studio> --profile <Profile> --output json`。`--source auto` 默认依次选择 `primaryContent.value`、`media`、`thumbnail`；需要特定来源时显式传 `--source`。
-11. 用户需要 View Feature 中的 PDF/文件时，使用 `monkeys data asset attachment download <Asset ID> --ontology <Ontology ID> --view <View ID> --field <Field ID 或唯一精确名称> --out <本地路径> --perspective <kernel|studio> --profile <Profile> --output json`。历史 Field 类型可能是 `img`，仍应按实际 Content-Type/文件内容称为 PDF 或附件，不要误称为图片。
+9. 只复用同一 Context、Team 模式、Data 合同、Ontology、View 和查询生成的 Cursor；CLI Cursor 会保留自动路由后的实际 Data Perspective，游标不匹配时重新查询。
+10. 用户需要读取、查看或保存 Asset 封面图片/媒体时，使用 `monkeys data asset media download <Asset ID> --ontology <Ontology ID> --out <本地路径> --profile <Profile> --output json`；用户明确指定视角时再补 `--perspective studio|kernel`。`--source auto` 默认依次选择 `primaryContent.value`、`media`、`thumbnail`；需要特定来源时显式传 `--source`。
+11. 用户需要 View Feature 中的 PDF/文件时，使用 `monkeys data asset attachment download <Asset ID> --ontology <Ontology ID> --view <View ID> --field <Field ID 或唯一精确名称> --out <本地路径> --profile <Profile> --output json`；用户明确指定视角时再补 `--perspective studio|kernel`。历史 Field 类型可能是 `img`，仍应按实际 Content-Type/文件内容称为 PDF 或附件，不要误称为图片。
 12. 下载成功后依据 CLI 返回的本地 `path` 展示或处理文件，并向用户报告来源 Field、大小和 SHA-256；不要把二进制正文塞入 JSON 或聊天文本。
 13. 两种下载都由 CLI 内部处理对象地址：公开 HTTPS 对象使用匿名、无身份 Header、无重定向、有界原子下载；对象明确返回 401/403/404 时，CLI 才请求 Server 生成短期签名并重试。CLI 不自行签名，任何规范或签名 URL 都不得进入结构化输出或聊天。网络错误、重定向、异常 Content-Type、超限或签名失败必须直接报告，不得使用普通 HTTP、Raw API 或手工 URL 兜底。
 14. 覆盖本地已有文件前必须得到用户对该精确路径的授权，并同时传 `--overwrite --yes`。默认最大 50 MiB；只有任务确有需要时才提高 `--max-bytes`，不得超过 1 GiB。
 
 参数和筛选条件始终以相应命令的 `--help` 为准。
 
+## Team 0 用法
+
+下面三类命令分别表示“发现 Team `0` 的 Ontology”“筛选 Team `0` 的 Asset”和“定位 Team `0` 中的 Kernel 子资源”：
+
+```bash
+monkeys data ontology list --scope all --perspective kernel --team 0 --profile <Profile> --output json
+monkeys data asset list --ontology <Ontology ID> --perspective kernel --team 0 --profile <Profile> --output json
+monkeys data view rows --ontology <Ontology ID> --view <View ID> --resource-team 0 --perspective kernel --profile <Profile> --output json
+```
+
+前两类输出应为 `teamMode=filter`、`effectiveTeamId=0`；第三类仍为 `teamMode=none`，并通过 `resourceLocator.teamId=0` 报告后端分区定位。不要同时传 `--team 0` 与 `--resource-team 0`，也不要把任一形式解释为“查询所有 Team”。
+
 `visible` 只表示当前身份可以读取，不代表可以创建、更新或治理。`data bucket` 和 `--bucket` 只用于旧脚本/旧部署兼容；新任务不得优先使用。

package/skills/monkeys/references/ontology-feature-search.md

@@ -12,14 +12,14 @@
 
 ## Agent 执行流程
 
-1. 按[Data 视角路由](data-perspective.md)确定 `--perspective`。内部开发默认 Kernel；Kernel 全局查询默认不传 `--team`，用户明确要求 Team 筛选时才传。用户明确要求 Studio 时使用 Studio 和明确 Team。
+1. 按[Data 视角路由](data-perspective.md)处理视角。用户明确要求时传 `--perspective studio|kernel`；未指定时省略，由 CLI 执行 Studio-first。Kernel 全局查询默认不传 `--team`，用户明确要求 Team 筛选时才传。
 2. 查询目标 Ontology 的 Feature Column：
 
    ```bash
-   monkeys data field list --profile <Profile> --perspective kernel --ontology <Ontology ID> --resource-team <数据 Team> --output json
+   monkeys data field list --profile <Profile> --ontology <Ontology ID> --resource-team <数据 Team> --output json
    ```
 
-   Kernel 下不要添加 `--team`；传已确认的 `--resource-team`。CLI 不会从 Ontology owner Team 自动推导；该 locator 不代表 Feature 查询被收窄到某个 Team。Studio 应改用明确的 `--team` 并移除 `--resource-team`。
+   自动模式可携带已确认的 `--resource-team` 供 Kernel 升级后定位；Studio 尝试不会使用它作为 Team 上下文。Kernel 下不要添加 `--team`，除非用户明确要求 Team 筛选。CLI 不会从 Ontology owner Team 自动推导。用户明确指定 Studio 时改用明确的 `--team` 并移除 `--resource-team`。
 
 3. 从返回项读取 `config.fieldKey`、`type` 和 `scopeContainerViewId`。只选择 `fieldKey` 非空、Ontology-global 且类型受支持的列；多个同名展示列不能按名称猜测。
 4. 使用 `--expression-json` 或复杂条件优先使用 `--expression-file`，并在 Kernel 命令继续传同一 `--resource-team`。不要手工包装 `filterConfigV2.expression`；CLI 会完成适配。
@@ -74,8 +74,8 @@ CLI 只校验 expression 公共结构和 JSON 标量形状。Feature 的真实
 
 - `DATA_SEARCH_EXPRESSION_INVALID`：请求未发送。修正节点路径、op、fieldKey、cmp、value 或表达式上限。
 - `DATA_SEARCH_EXPRESSION_CONFLICT`：请求未发送。删除重复的 `filterConfigV2.expression` 或 `--expression-*` 之一。
-- `DATA_RESOURCE_TEAM_REQUIRED`：缺少已确认的数据资源 Team。停止并向用户请求 `--resource-team`；不得尝试 owner Team、`0`、Session Team、Raw API 或在空结果后补 Team 重试。
-- `DATA_TEAM_ROLE_CONFLICT` / `DATA_RESOURCE_TEAM_NOT_APPLICABLE`：`--team` 与 `--resource-team` 角色冲突，或当前不是显式 Kernel Ontology 读取。按 recovery 修正参数，不得改走 Raw API。
+- `DATA_RESOURCE_TEAM_REQUIRED`：缺少已确认的数据资源 Team。停止并向用户请求 `--resource-team`；不得猜 owner Team、`0` 或 Session Team，也不得使用 Raw API 或在空结果后补 Team 重试。若用户或权威资源元数据已确认 data resource Team 为 `0`，则应显式传 `--resource-team 0`。
+- `DATA_TEAM_ROLE_CONFLICT` / `DATA_RESOURCE_TEAM_NOT_APPLICABLE`：`--team` 与 `--resource-team` 角色冲突，或 locator 不适用于明确 Studio/旧 Bucket 读取。按 recovery 修正参数，不得改走 Raw API。
 - `HTTP_400`：重新读取 Feature Column，核对 `config.fieldKey`、类型、比较符、全局作用域和不支持边界。不得 Raw API 降级。
 - `HTTP_503`：Feature 搜索依赖的 ES/索引不可用。向用户明确报告服务暂不可用和 `retryable`；不得改为 PG EAV 扫描、Raw API、模糊搜索或其他静默兜底。
 - 空结果：先检查 Perspective、Team、Ontology、权限和真实查询条件；只有紧邻已确认写入时才按最终一致性做一次有界重试。

package/skills/monkeys/references/ontology-model.md

@@ -37,7 +37,8 @@
 
 ## Kernel 与 Studio 可见性
 
-- 内部开发任务默认由 Skill 显式选择 Kernel；Kernel 全局读取没有用户 Team 作用域，显式 `--team` 只用于用户明确筛选。Ontology 子资源需要后端数据资源 Team 时传已确认的 `--resource-team`；owner Team 与 data resource Team 可以不同，Agent 和 CLI 都不得猜测。
+- 用户未指定视角时由 CLI 先查 Studio，确定性为空且当前账号有 Kernel 权限时再升级；Skill 不默认选择 Kernel。Kernel 全局读取没有用户 Team 作用域，显式 `--team` 只用于用户明确筛选。Ontology 子资源需要后端数据资源 Team 时传已确认的 `--resource-team`；owner Team 与 data resource Team 可以不同，Agent 和 CLI 都不得猜测。
+- Team `0` 是共享/系统数据分区，不是“所有 Team”。Team `0` 的 Ontology 可作为共享 Schema 被普通 Team 复用，所以 `Ontology.teamId=0` 不代表其中所有 Asset 或子资源都位于 Team `0`；直接查询已确认的 Team `0` 分区用 `--team 0`，定位已确认位于该分区的 Kernel 子资源用 `--resource-team 0`。
 - Studio 结果受当前账户和 Team 可见性限制；用户明确要求 Studio 时必须遵守。
 - Kernel 权限不足且用户未指定视角时，Skill 只有在存在等价 Studio 操作并先在聊天中告知范围收窄后，才可显式降级。
 - 后台能找到 Asset、前台某个 View 找不到，常见原因是 Studio 权限或 Membership/Filter 条件不同，不代表 Asset 不存在。

package/skills/monkeys/references/safety-errors.md

@@ -8,7 +8,7 @@
 
 只有 `retryable=true` 且操作本身安全或带稳定幂等键时才有限重试。退出码 3/4/7 不得通过 Raw API 绕过。
 
-`DATA_RESOURCE_TEAM_REQUIRED` 表示 Kernel Ontology 读取缺少已确认的 data resource Team；`DATA_TEAM_ROLE_CONFLICT` 表示同时传了用户筛选/上下文 `--team` 和资源定位 `--resource-team`；`DATA_RESOURCE_TEAM_NOT_APPLICABLE` 表示把 locator 用在 Studio、legacy perspective 或旧 Bucket。三类错误都发生在请求前。不得硬编码 `0`、使用 owner Team 或 Session Team 猜测、切换 Studio、调用 Raw API或等业务空结果后重试；应向用户报告 Ontology ID、错误和 recovery。
+`DATA_RESOURCE_TEAM_REQUIRED` 表示 Kernel Ontology 读取缺少已确认的 data resource Team；`DATA_TEAM_ROLE_CONFLICT` 表示同时传了用户筛选/上下文 `--team` 和资源定位 `--resource-team`；`DATA_RESOURCE_TEAM_NOT_APPLICABLE` 表示把 locator 用在明确 Studio 或旧 Bucket 读取。三类错误都发生在请求前。不得把 `0` 硬编码为默认值，也不得使用 owner Team 或 Session Team 猜测、调用 Raw API 或继续盲试；用户或权威资源元数据已确认共享/系统数据分区时，`--resource-team 0` 是有效的显式定位。应向用户报告 Ontology ID、错误和 recovery。
 
 ## Secret 与输出