yoyoboot repo owner

准备修改代码、配置或文档，却不确定应该在哪个模块处理时，使用此命令定位正式 owner、适用规则与执行边界。它帮助开发者和 Agent 减少改错位置、重复实现及验证范围不明确的问题。

基本用法

yoyoboot repo owner <target> [--repo <path>] [--json]

在 YoyoBoot 源码仓库中运行

在仓库根目录执行，查询当前仓库中真实存在的 CLI package。无需安装全局 yoyoboot；首次 bootstrap 可能执行构建。脚本和 Agent 查询建议加上 --json。

pnpm --dir tools/yoyoboot-cli run cli -- repo owner tools/yoyoboot-cli/package.json --json

查询 capability

已安装 yoyoboot 时可直接执行；仓库内也可使用上面的 pnpm 入口并替换目标。常见 capability 前缀为 package:、spec: 和 tool:；先用 yoyoboot repo capabilities --json 查询当前仓库实际暴露的 ID。

yoyoboot repo owner package:@yoyoboot/cli --json

参数

参数	必填	说明
target	是	仓库相对路径或当前已暴露的 capability ID。
--json	否	以 JSON 输出完整结果信封，供机器读取。
--help	否	展示帮助；yoyoboot --help / yoyoboot <command> --help。
--repo <path>	否	显式指定仓库查找起点；缺省从当前工作目录向上查找。

示例

查询一个 package 的 owner

yoyoboot repo owner packages/example/src/service.ts --json

以下命令针对固定示例仓库，其中 packages/example 不是 YoyoBoot 源码仓库的现有目录。JSON 是公开投影：省略顶层 source、data.source、data.owner.source、data.ruleOwner.source 和 data.executionOwner.source，以 <rule-source> 替代规则文件位置。实际结果仍返回这些来源；scripts 与规则链随目标仓库变化。

{
  "command": "repo owner",
  "status": "ok",
  "findings": [],
  "data": {
    "schemaVersion": "2.0.0",
    "path": "packages/example/src/service.ts",
    "owner": {
      "id": "packages/example",
      "directory": "packages/example"
    },
    "ruleOwner": {
      "id": "packages/example",
      "directory": "packages/example"
    },
    "rules": [
      {
        "kind": "rules",
        "path": "<rule-source>",
        "owner": "."
      },
      {
        "kind": "rules",
        "path": "<rule-source>",
        "owner": "packages/example"
      }
    ],
    "executionOwner": {
      "directory": "packages/example",
      "name": "@example/package",
      "scripts": {
        "verify": "example-check"
      }
    },
    "sources": [
      {
        "kind": "rules",
        "path": "<rule-source>",
        "owner": "."
      },
      {
        "kind": "rules",
        "path": "<rule-source>",
        "owner": "packages/example"
      },
      {
        "kind": "manifest",
        "path": "packages/example/package.json",
        "owner": "packages/example"
      },
      {
        "kind": "runtime",
        "path": "packages/example/src/service.ts",
        "owner": "packages/example"
      }
    ]
  }
}

返回结果

只读查询当前工作树，返回目标的正式归属、适用规则链及执行范围。

主要字段

字段	说明
command	成功时为 repo owner；入口捕获的失败为 cli，失败分支应使用诊断码判断。
status	结果信封支持 ok / warn / error；本命令正常查询为 ok，失败为 error。
source	JSON 顶层的命令实现来源，结构为 { kind, path, owner }；不同于 data.source 的工作树事实来源。公开示例省略此字段。
findings	诊断数组；查询成功时为空，失败时包含诊断信息。
findings[].code	稳定诊断码，用于程序分支；不解析自然语言错误消息。成功示例中的 findings 为空数组。
findings[].status	单条诊断的级别：ok / warn / error。本命令失败时为 error。
findings[].message	面向人的说明，内容不作为稳定机器协议。
findings[].detail	可选的补充说明；缺省时不返回，不应假设存在。
data	查询成功时包含下面的 owner 结果；入口捕获的失败不返回此字段。
data.schemaVersion	仓库结果的合同版本，用于识别字段及兼容范围。
data.path	解析后的仓库相对路径；使用 capability 查询时，解析为该 capability 的正式来源路径。
data.source	本次查询的工作树事实来源；公开示例省略此字段，实际结果仍返回。
data.owner	目标最终由谁负责，来源可能是 package manifest、项目文件、规格或正式规则入口。source 给出 owner 的判断依据。
data.owner.id	正式 owner 标识；当前仓库合同使用其仓库相对目录，例如 tools/yoyoboot-cli。
data.owner.directory	正式 owner 的仓库相对目录；仓库根用 . 表示。
data.owner.source	正式 owner 的判断依据，结构为 { kind, path, owner }。
data.ruleOwner	距离目标最近的规则边界；可以与事实 owner 不同，没有规则时为 null。source 指向该规则来源。
data.ruleOwner.id	最近规则边界的标识，当前使用其仓库相对目录；仅在 ruleOwner 非 null 时存在。
data.ruleOwner.directory	最近规则边界的仓库相对目录；仅在 ruleOwner 非 null 时存在。
data.ruleOwner.source	该规则的正式来源，结构为 { kind, path, owner }；仅在 ruleOwner 非 null 时存在。
data.rules	全部适用的祖先规则来源。按返回位置读取，不能只读取最近一层。
data.executionOwner	最近可执行 package 的目录、名称和 scripts，source 指向其 manifest；不属于 package 时为 null。该命令不运行 scripts。
data.executionOwner.directory	可执行 package 的仓库相对目录；仅在 executionOwner 非 null 时存在。
data.executionOwner.name	package manifest 声明的包名；仅在 executionOwner 非 null 时存在。
data.executionOwner.scripts	manifest 声明的脚本映射 { 脚本名: 命令字符串 }，可能为空对象；仅在 executionOwner 非 null 时存在。
data.executionOwner.source	该 package manifest 的正式来源，结构为 { kind, path, owner }；仅在 executionOwner 非 null 时存在。
data.sources	判断依据的正式来源，区分 rules、manifest、spec、runtime、docs 和 generated-reference。

使用说明

• target 接受仓库相对路径或真实 capability ID；上面的仓库调用与 capability 示例可用于实际查询。
• 查询只读，不支持 --dry-run。
• owner 回答目标归哪个正式模块负责，ruleOwner 回答最近一层规则来自哪里。例如，固定示例仓库若只保留根规则，查询 packages/example/src/service.ts 时，owner.directory 仍是 packages/example（依据 package manifest），ruleOwner.directory 则是 .（依据根规则）；两者不同是正常结果。
• 所有 Source 对象都包含三个字符串字段：kind 是 rules / spec / manifest / runtime / docs / generated-reference 之一；path 是事实位置或 git:working-tree 等来源标识；owner 是来源责任标识。data.source、各 owner 的 source、rules[] 和 sources[] 使用同一结构。规则来源可指向规则文件，来源标识不一定是可直接打开的文件路径。
• 通用输入失败码包括 invalid-arguments、unknown-option、duplicate-option、missing-option-value、unexpected-option-value 和 read-only-dry-run-unsupported；仓库定位失败码为 start-directory-missing 或 repo-root-not-found。预期失败返回 status=error、command=cli 和退出码 2，不返回 data；未预期错误使用 unexpected-error 与退出码 1。
• --help 返回帮助文本，即使同时指定 --json 也不输出 owner JSON。
• 路径支持新建或已删除的文件；成功确定 owner 不证明目标文件存在，也不证明验证已通过。
• 自动化可依赖这里说明的稳定字段；JSON 属性顺序、自然语言消息和未说明的内部细节不属于保证。

退出码

Exit code	含义
0	查询成功。
2	预期失败，例如参数无效、capability 未暴露、owner 缺失或歧义。
1	未预期程序错误。

常见错误

unsupported-capability

当前仓库没有暴露所查询的 capability。

处理方式：先运行 yoyoboot repo capabilities --json，使用返回的真实 capability ID 重试。

owner-ambiguous

目标存在多个竞争的 owner，无法唯一确定，例如同目录有多个 csproj。

处理方式：明确指定目标项目文件或核实重复的 capability 来源；CLI 不随机选择 owner。

owner-missing

没有可以成立的正式 owner 或规则入口。

处理方式：核实并补齐正式 manifest、规格或责任入口，再重试查询。

path-outside-repository

目标路径或它的链接指向仓库外。

处理方式：使用仓库内路径，并检查目标路径的符号链接。

推荐后续命令

查询真实仓库 capability，再选择对应 ID。

yoyoboot repo capabilities --json

沿用上面的真实仓库目标，读取 owner 的相关正式事实与验证入口；查询其他改动时替换目标路径。仓库内可使用上面的 pnpm 入口。

yoyoboot repo inspect tools/yoyoboot-cli/package.json --json

沿用上面的真实仓库目标，规划该 owner 的已有检查；修改其他文件时替换为实际改动路径。计划不执行检查，不是通过证据。仓库内可使用上面的 pnpm 入口。

yoyoboot repo verify-plan tools/yoyoboot-cli/package.json --json

按当前工作树改动规划验证范围。

yoyoboot repo verify-plan --changed --json

相关命令

• yoyoboot repo capabilities

• yoyoboot repo inspect

• yoyoboot repo verify-plan

• yoyoboot repo map

• yoyoboot repo doctor

• Reference 合同版本：1.0.0

• 结果合同版本：2.0.0

• 源码产品版本：10.5.7（不代表 registry 发布状态）。