mowgli

Mowgli Sync

你正在使用 Mowgli，这是一款由 AI 驱动的产品设计与范围界定工具。此 技能可让你通过 mowgli CLI 将真实代码库中的设计推送到 Mowgli 项目（并将其拉回）， 该 CLI 可通过编程方式访问 Mowgli。

Mowgli 是一个类似 Figma 的画布，旨在快速迭代设计。用户可以进行大范围或精细的修改、导出为 多种格式、创建原型，并使用版本历史记录。用户可能会使用 Mowgli 对应用、网站或其他 项目进行视觉实验、重新设计、比较和构思。作为用户的编码 Agent，你需要协助真实代码库与 Mowgli 项目之间的互通。

开始操作前，请通读本文档。最重要的一点：Mowgli 项目由规范支持。屏幕、SPEC.md 和 frontend.xml 必须始终 保持同步。edit 命令会遵循最佳实践，自动完成这三项工作。

---

1. Mowgli 项目是什么

Mowgli 项目以一组小巧、自成一体的文件来表示产品的前端：

• SPEC.md - Markdown 规范：电梯演讲、用户旅程和数据模型。

• frontend.xml - 一个 <frontend_common> 块（共享界面框架说明），后接 一个 <screens> 列表。每个 <screen> 条目如下：

  <screen name="Account Settings" component="SettingsScreen">
    <summary>One-line description of the screen.</summary>
    <contents>
      The overall content and design elements, deliberately staying away from tiny
      details (exact layout, colors, spacing). Markdown bullets are fine here.
    </contents>
    <state id="default" name="Active Subscriber">1-2 sentence description.</state>
    <state id="freePlan" name="Free Plan">...</state>
  </screen>
  

  • component 与 .tsx 文件名（{component}.tsx）一致，并且是组件名称； name 是易于理解的标题。
  • <summary> 是一句话简介；<contents> 是更完整但仍保持高层次的描述。
  • 每个 <state> 都有一个 id（传给组件的 state 属性）、一个 name，以及作为正文的一到两句描述。

• <id>.tsx - 每个屏幕对应一个 React 组件。此代码需满足以下约束：

  • 图标只能来自 lucide-react
  • 样式必须纯 Tailwind，并使用 bg-[#abcdef]、text-[#0F172A] 这样的精确类名
  • 所有 Google Fonts 均可通过任意字体系列语法使用，例如 font-['Open_Sans']
  • 组件接收单个 state 属性，并渲染相应状态

规范的屏幕文件如下：

import * as React from 'react';
import * as Icons from 'lucide-react';

export type OnboardingScreenProps = { state: string };

/**
  ...docs about OnboardingScreen...
  States:
  - `step1`: Step 1, consisting of a name for the user's first event, and a skip
    button to avoid creating a first event.
  ...
*/
const OnboardingScreen = (props: OnboardingScreenProps) => (
  <div className="min-w-full h-full overflow-y-auto">
    <div className="bg-[#abcdef] text-[#112233] text-lg">Onboarding</div>
    {/* ... */}
  </div>
);

export default OnboardingScreen;

在一些场景中，frontend.xml（尤其是屏幕描述及其状态列表）会作为承载关键信息的简要屏幕说明，用于替代 token 占用过高的完整 .tsx 文件。请确保其内容准确。

Mowgli 使用版本控制：项目有一个 HEAD（当前）版本和线性历史记录。每次 edit 都会生成一个新版本。项目级元数据（每个项目一个自由格式字符串）和版本级元数据（每个版本一个自由格式字符串）可用于持续追踪代码库与 Mowgli 之间的关系。

---

2. CLI

无需安装即可通过 npx mowgli-cli ... 调用。所有内容都会以 JSON 或原始字符串的形式输出到标准输出；退出代码表示成功或失败。服务默认地址为 https://app.mowgli.ai；可通过 --base-url <url> 或 $MOWGLI_BASE_URL 覆盖。

命令	功能
mowgli login / mowgli logout	管理已存储的凭据（经浏览器批准的 CLI 授权）
mowgli projects	列出该凭据有权访问的项目
mowgli -p <projectId> info	项目信息，包括项目级互操作元数据
mowgli -p <projectId> set-meta [text]	读取或设置项目级元数据（通过文本参数或标准输入）
mowgli -p <projectId> versions [--limit N --offset N]	分页查看版本历史
mowgli -p <projectId> version <n>	显示一个版本
mowgli -p <projectId> version <n> set-meta [text]	读取或设置版本级元数据
mowgli -p <projectId> files [--version <v>]	列出逻辑文件（SPEC.md、frontend.xml、屏幕）
mowgli -p <projectId> read <path> [--version <v>]	打印一个文件的内容
mowgli -p <projectId> diff [--stat] [--from <v> --to <v>] [paths...]	显示统一差异，或 --stat 摘要
mowgli edit --lint -f <file>...	离线预检：标记由 -f 文件导入但未提供的本地文件（不调用 API）
mowgli -p <projectId> edit [--instruction <text>] [-f <file>]...	通过 Mowgli Agent 应用自然语言编辑

命令示例

# Who can I see? (find the target project's id)
mowgli projects

# First-contact recon on a project
mowgli -p <projectId> info                 # includes the project metadata string
mowgli -p <projectId> versions --limit 20  # history; check userdata on recent versions
mowgli -p <projectId> files                # what screens exist at HEAD
mowgli -p <projectId> read SPEC.md
mowgli -p <projectId> read frontend.xml
mowgli -p <projectId> read DashboardScreen.tsx

# What changed between two versions (cheap overview, then full patch)
mowgli -p <projectId> diff --stat --from 6
mowgli -p <projectId> diff --from 6 --to 9 DashboardScreen.tsx

# Write project metadata (first connect) - via stdin
echo "Codebase: github.com/acme/app (branch main, commit a1b2c3d).
Stack: React 18 + TS, Tailwind v3 semantic tokens, lucide-react. Font: Geist.
Path map: DashboardScreen.tsx <- src/pages/DashboardPage.tsx (+ ShellHeader, Dropdown).
Theme: light only; token->hex bg #FFFFFF, fg #0F172A, primary #E51A4C ..." \
  | mowgli -p <projectId> set-meta

# Apply an edit: instruction on stdin, real source files appended with -f
mowgli -p <projectId> edit \
  -f src/pages/DashboardPage.tsx \
  -f src/components/ShellHeader.tsx \
  -f tailwind.config.ts \
  < /tmp/dashboard-instruction.txt

# Record what you did on the resulting version
mowgli -p <projectId> version 7 set-meta "Synced DashboardScreen from commit a1b2c3d ..."

关于 edit 的说明：

• 指令来自 --instruction 或管道传入的标准输入。
• 每个 -f <file> 都会将该文件的内容附加到指令中，并用 --- BEGIN FILE: <name> --- / --- END FILE: <name> --- 标记包裹。使用 -f 将 实际代码库源文件（屏幕及其依赖项、主题）提供给 Agent。
• 成功时，响应包含 Agent 的自由文本消息和简洁的统计摘要： vN -> vM 版本升级、每个文件一行 A/M/D <path> +added -removed、汇总数据，以及 指向 mowgli -p <id> diff --from N --to M 的提示，可用于查看完整补丁。 完整补丁不会直接输出；只有在摘要看起来有误时，才使用 diff 获取。
• 如果没有差异，说明编辑没有改变任何内容——阅读消息，修正指令或上下文，然后重新完整执行。

---

3. 与 Mowgli 项目协作的规则

前提条件

• 项目级互操作元数据。 编码 Agent 可以读取和写入与项目关联的任意字符串。遇到上下文中尚未包含的项目时，Agent 应始终读取并写入此信息。应使用这些元数据来识别与 Mowgli 项目关联的代码库，说明 Mowgli 项目与实际运行产品之间的关系（忠实副本、更大产品的一部分等），定义实际代码库对组件库和设计系统的遵循情况，并提供实际代码库与 Mowgli 项目之间的路径映射和目录组织信息。
• 版本级互操作元数据。 Mowgli 完全采用版本控制：项目有一个 HEAD（当前）版本，以及一条记录自项目创建以来每项变更的线性版本历史。版本级互操作元数据是与某个版本关联的自由格式字符串，Agent 可以读取和写入。在执行任何类型的 Mowgli <-> 代码库同步时，Agent 应始终读取并写入此信息。Agent 应写入以下信息：
  • Agent 对项目所做编辑的上下文（例如，为与实际代码库同步或纠正某些差异而进行的编辑）
  • 与该版本对应的当前提交短哈希
  • 对 Agent 日后有用的其他元数据，例如省略的功能或与实际状态有意保持的差异

协作规则

Mowgli 项目以规范为依据，并依赖对屏幕和状态的准确呈现。

对屏幕所做的任何更改，都必须同步修改 SPEC.md 和 frontend.xml，确保它们完整反映应用中的变化。

尤其重要的是，要收集环境信息，包括应用后端的信息，以了解屏幕或功能所涉及的真实用户流程，而不是只把设计交给 Mowgli。Mowgli 是一款由规范驱动的设计工具，它依赖与屏幕设计保持同步的 SPEC.md，才能提供高度贴合上下文的建议、支持头脑风暴，并允许对项目进行大范围更改。

此外，frontend.xml 中的屏幕信息，尤其是状态列表，是项目至关重要的基础文档，提供整个应用的全局视图，而不只是理想流程。务必发现所有重要的模态框、下拉菜单、弹出层，以及屏幕的所有相关状态和子状态，并在 Mowgli 中如实呈现。

每次更改屏幕，都必须同步修改 frontend.xml 中相应的部分。可以使用 edit 命令／端点一次性应用这些更改，因为它由 Agent 提供支持。

首次访问任何项目时，都必须检查项目元数据，并在必要时编写或更新，以确保 Agent 对项目的认知与此前记录的信息一致。

Mowgli 项目每次更改后，都必须进行最终版本元数据写入，简要记录所做更改、关联 Mowgli 与代码库版本的提交短哈希或其他版本指针，以及今后忠实执行类似操作所需的其他信息。

4. 同步标准操作流程

Mowgli -> 代码库同步

1. 列出所有项目。
2. 确认用户指的是哪个项目。如果有多个项目且无法确定，请询问用户。记下项目 ID。
3. 检查所选项目的元数据。如果其中有矛盾信息，请与用户确认并解决。
4. 如果 Mowgli 项目中尚无元数据，则写入以下信息：
   • 当前代码库（GitHub 名称、用途等）
   • 软件技术栈
   • 使用到的组件库和其他代码库级别的详细信息（如有）
   • 首次同步时的当前提交（如有）
   • 其他有助于未来编码 Agent 重新了解项目背景的顶层备注或观察
5. 获取版本信息，查看是否存在版本级元数据标签。（与用户确认并解决任何歧义。）
6. 从 Mowgli 项目获取规范和 frontend.xml 文件，并了解项目。如果上一步的标签表明此前已进行过工作，请使用 diff 端点查看相较于上一个已知版本有哪些变化，并记录这些变化。
7. 根据需要逐屏获取内容，必要时查看差异，并将更改应用到代码库。用户已审核 Mowgli 中的状态，因此应将其视为事实来源，并以差异界定范围：只准确转换发生变化的内容，不多做任何更改。不要从版本标题或描述中揣测意图（它们仅用于帮助理解差异，不是额外指令），除非用户明确要求，或确实无法在不参考其意图的情况下忠实应用更改。
8. 最后写入版本元数据，标记该版本已与代码库保持同步，并注明日期、时间和提交信息。

代码库 -> Mowgli 同步

1. 列出所有项目，并按照上文步骤 1-2 的方式准确识别目标项目。 记下项目 ID。
2. 检查项目元数据。如果缺失或已过时，请写入/更新元数据（代码库身份、软件技术栈、组件库，以及真实代码库与 Mowgli 项目之间的路径映射）。继续操作前，先与用户解决任何矛盾。
3. 获取版本信息并阅读版本级元数据，找到最后同步的版本及其记录的提交短哈希。这是代码库差异比较的基准。
4. 确定代码库自该基准以来有哪些更改（例如，git diff <lastSyncedCommit>），并将更改的源文件映射到受影响的 Mowgli 屏幕，以及 SPEC.md 和 frontend.xml。如果没有记录的基准，则将所有相关屏幕视为已更改。
5. 对每个受影响的屏幕，整理编辑 Agent 所需的上下文：将目标 Mowgli 文件作为 @ 提及项（@SPEC.md、@frontend.xml、@<Screen>.tsx），并以内联方式粘贴真实代码库代码，包括忠实渲染所需的依赖项（例如 tailwind.config.ts 等主题文件、src/components/ui/button.tsx 等共享组件，以及依赖树中的其他内容）。向已有屏幕的项目中添加新屏幕时，还要至少将一个现有屏幕作为勿改动的参考进行 @ 提及——端点要求这样做，而且这能让新屏幕沿用项目的共享界面框架和样式。
6. 运行 edit --lint，每次调用所含信息不超过 4-5 个大型屏幕的量（复杂更改时相应减少）。Agent 可能查看或更改的每个文件都必须在同一次调用中通过 @ 提及；调用之间无状态，因此每次调用都必须完整自包含。
7. lint 会标记导入层级中缺失的文件。检查 lint 输出，调整提供的文件列表，直到结果符合要求。然后，最后运行一次 edit 调用，将更改应用到 Mowgli。
8. 检查结果。如果响应中没有差异，说明编辑没有更改任何内容：阅读 Agent 的消息，修正指令或上下文，并作为全新的调用重新运行整个请求。对剩余批次重复步骤 5-6。
9. 确认 SPEC.md 和 frontend.xml 已反映所有发生更改的屏幕和状态。编辑 Agent 应会让它们保持同步，但请务必核实，因为它们对系统其余部分至关重要。
10. 在生成的版本上写入版本元数据：简要说明已应用的更改、此版本对应的代码库提交短哈希，以及任何有意保留的差异或省略的功能，以供日后参考。

---

5. 如何编写优质的 edit（每次推送前阅读）

edit Agent 由 Agent 驱动，但注重精确：专为忠实转换而非构思创意而优化。它已了解操作机制——规范的 .tsx 格式、根据你提供的主题文件将语义化 Tailwind 令牌解析为准确的十六进制值、保持 SPEC.md 和 frontend.xml 同步，以及为新屏幕编写 <screen> 条目。无需在指令中复述这些内容。请专注于 Agent 无法从 Mowgli 内部获取的两件事。

1. 真实源文件，通过 -f

屏幕界面以及所有绘制可见 UI 的依赖项：叶子组件、主题／令牌文件（tailwind.config、定义令牌的 CSS）、共享小组件。如果省略某个 UI 部分的源文件，Agent 就无从依据，只能自行臆造；如果你的文字说明只是猜测或含糊带过，Agent 就会忠实呈现你的猜测。几乎所有糟糕的提交都源于此——请参阅下面的导入树和保真度规则。提供主题文件，而不是手动抄写十六进制颜色表（Agent 会自行解析令牌）；只有在无法从你提供的文件中推导出映射时，才明确写出映射。说明要渲染哪种主题（浅色／深色），因为源文件可能同时支持两种主题，而 Agent 不会自行猜测。使用 -f 传入文件并不意味着你必须先阅读它——Agent 会读取你转交的内容，所以请大胆按名称转交叶子文件，把你自己的阅读时间留给行为逻辑（见下方关于先运行 lint 的说明）。

2. 项目理解——真正的关键

这部分存在于你的脑海中，也分散在更广泛的代码库里，并非集中于某个文件，因此只有你能提供。请简洁说明（Agent 会扩展内容，所以不要写得太冗长，但也不要含糊带过）：

• 每个屏幕是什么，以及它在产品中的作用；
• 屏幕之间如何关联，用户如何进入这些屏幕——入口、导航，以及它们所属的流程（要阅读路由和后端代码，而不只是屏幕文件）；
• 屏幕涉及哪些用户旅程，以及哪些数据模型实体／字段；
• 每个屏幕的完整状态列表（第一个状态为默认状态）——屏幕可渲染的状态只有你能从代码中完整列出（见下方的状态规范）。

仍属必需，但成本不高

• 使用 @ 提及 Agent 可能会读取或修改的每个 Mowgli 侧文件（@SPEC.md、@frontend.xml、@<Screen>.tsx）。文件可见性有严格限制：如果 Agent 需要某个未提及的文件，它会拒绝整个请求。
• 向非空项目添加屏幕时，至少使用 @ 提及一个现有屏幕（@<ExistingScreen>.tsx）——不能只提及 @SPEC.md 和 @frontend.xml。接口要求提供现有屏幕，否则会拒绝请求（“请在上下文中至少包含一个现有屏幕”）。这至关重要，并非走形式：现有屏幕能帮助 Agent 了解共享界面框架（页眉、导航、页脚）、配色方案和布局规范，让新屏幕与项目保持一致，避免出现细微偏差。将它标记为禁止修改（见下一条），仅供参考。
• 添加到现有项目时，明确说明“禁止修改”的范围：必须保持逐字节不变的现有状态／屏幕。

先运行 lint 梳理文件树，然后在每次编辑前再次运行 lint（不要跳过）

推送出错最常见的原因，是只发送父组件，没有包含实际绘制 UI 的子组件，然后凭记忆描述这些子组件。Agent 会忠实地呈现你的猜测，最终画面却不对。

因此，请尽早运行 lint，在开始阅读之前就执行：只指定根文件（页面／屏幕，以及可能的顶层视图），即可低成本列出整棵导入树，无需打开任何叶子文件。

mowgli edit --lint -f src/pages/DashboardPage.tsx

输出的文件树就是绘制 UI 的文件地图。用它来决定要发送哪些文件——并注意，大多数叶子组件只需按名称通过 -f 添加即可，无需完整阅读。Agent 会读取你传入的源文件；你不必为了转发一个按钮、卡片、横幅或主题文件而事先阅读它。阅读成本很高，因此应把时间花在真正有价值的地方：了解产品行为——屏幕的用途、用户流程和入口、数据模型，以及完整的状态列表（第 5.2 节）。只有在必须描述源代码本身无法说明的内容时（例如，需要确定该组件应呈现哪些内部状态），才预先阅读叶子文件。低成本地转发文件，再深入阅读行为，比打开文件树中的每个文件更节省 token。

然后，确定要发送的文件集合后，最后再对计划发送的每个文件运行一次 lint，并在调用 edit 之前解决每个 [missing] 节点：

mowgli edit --lint -f <every file you plan to send>

对于每个 [missing]，都要审慎决定：要么通过 -f 添加该文件，要么明确判断它不会绘制可见 UI（例如 hook、类型、上下文或纯逻辑工具函数），并说明原因。运行 edit 时不能留下尚未处理的 [missing] 条目——那个未经检查的叶子，正是最终会导致画面错误的文件。

此检查只依据基本文件名，且会忽略裸 npm 包和资源，因此它标出的是候选项，并非确定结果：它无法发现通过无法解析的路径别名引入的子项，而 [ok] 也只表示已提供一个具有相同基本文件名的文件。因此，干净的检查结果只是最低要求，不是万无一失——你仍需真正检查屏幕的渲染路径，一直追踪到叶子文件。

枚举状态（不要敷衍）

“状态”指任何在视觉上不同的呈现。可通过以下方式查找：

• 追踪每个控制覆盖层显示与否的布尔值（用于模态框、确认对话框、内嵌表单的 useState(false)）。每种打开／关闭状态都算一种状态。
• 将复杂组件视为状态机，而不是一种状态。一个模态框可能包含内部步骤——套餐选择器可以分支为费用预览、价格参考、创建团队和取消确认等子视图。将每个分支分别列为一种状态。
• 覆盖空、加载、错误和成功等变体，而不只是理想路径。

批量大小

• 新屏幕：每次调用 edit 大约处理 2–5 个。每个新屏幕 .tsx 都必须在同一次 edit 中于 frontend.xml 里添加对应的 <screen> 条目，否则编辑会因“has no spec”而被拒绝。创建屏幕时，请明确告知 Agent 这一点。
• 复杂的单个屏幕（状态多／布局复杂）：每次调用处理一个屏幕。应根据复杂程度缩减批量，而不只是看数量。
• 增量添加时不要一次只添加一种状态；这样会造成不必要的琐碎操作。一次编辑中应为现有屏幕添加多个状态。

根据结果核验，而不是条件反射

编辑响应已经返回了统计摘要（修改的文件、每个文件的 +/- 行数、版本升级）。请阅读该摘要。在常见情况下，如果结果符合预期——正确的文件发生了修改、新屏幕增加了预期的行数、没有修改任何标记为“不要触碰”的内容——就可以了，继续下一步。不要每次编辑后都条件反射地重新读取 .tsx 和 frontend.xml：这会浪费 token 和时间，而结果几乎总是表明编辑成功。

只有当摘要给出理由时，才通过 diff --from N --to M 获取完整补丁，或重新读取文件：没有差异（编辑未产生任何变化——修正后重试）、文件集合与预期不符、行数可疑（“小幅”修改却重写了文件，或“仅添加”的修改却删了行）、修改了禁止触碰的文件，或用户报告了问题。

---

6. 来之不易的经验教训（需要避免的保真度失误）

这些都来自实际推送中出现的问题。每个问题的根源都在于指令或上下文选择，而不是 Agent。

• 沿着导入树一直追踪到叶子组件。不要停在视图或页面。 如果实际 UI 位于导入的子组件中（HeaderActions、CanvasControls、ChatBubble、问题卡片包装器），仅提供 AppHeader.tsx、DesignView.tsx 或 ChatPanel.tsx 这样的父组件是不够的。如果只提供父组件并凭记忆描述子组件，子组件就会生成错误。打开每个对可见 UI 有贡献的导入组件，并通过 -f 提供它，或者根据其实际源码进行描述。mowgli edit --lint 的存在就是为了强制执行这项检查：每次推送前都要运行，并解决它报告的所有 [missing] 项（参见第 5 节的关卡）。这是一种强制机制，用来阻止你在未检查的情况下发送内容，而不能替代你亲自阅读渲染路径。
• 绝不要用“使用看起来合适的图标”或“几个有代表性的按钮”来含糊带过。 这等于要求编造。实际有七个控件（积分、反馈、分享、在线状态、连接 MCP、导出、主题）的页眉，如果你只列出两个，就只会渲染两个。
• 不要把实际不同的状态简化成相同状态。 如果你说“状态 B：与 A 相同，但文本不同”，即使你提供的源码显示布局不同，Agent 也会生成几乎相同的屏幕。请从结构上描述实际差异。
• 可以使用示例数据，但要明确标注。 你编造的价格、名称、日期和文案并非来自实时 API。请在版本元数据中注明这些值是代表性示例，以免未来同步时将其误认为真实数据。
• 编辑是无状态的。 你无法向之前的编辑对话追加内容。如果编辑被拒绝或结果有误，请将完整修正后的指令和所有新需要的文件一起，作为全新的调用重新运行。
• 并发： 如果项目中已有其他操作正在运行，当前操作会失败。请按顺序执行编辑；每次 edit 都会基于当前 HEAD 构建。
• Shell 引号（zsh）： 在 zsh 中，未加引号的变量不会进行单词拆分，因此将标志存入变量（B="--base-url x"; mowgli $B ...）会把它们作为一个参数发送。请直接写入标志，或用引号或数组括起它们。

---

7. 首轮检查清单

用户要求将代码库推送到 Mowgli 时：

1. mowgli projects -> 确定项目 ID（如果不明确，请向用户确认）。
2. mowgli -p <id> info -> 读取项目元数据；与用户核对并解决矛盾；如果元数据缺失或过时，则编写/更新元数据（代码库、技术栈、组件库、路径映射、主题令牌->十六进制颜色值表、当前提交）。
3. mowgli -p <id> versions -> 读取最近版本的 userdata，找到上次同步的提交；以此作为差异基线。
4. 将变更的源文件映射到受影响的屏幕 + SPEC.md + frontend.xml。
5. 对每个屏幕：先运行 mowgli edit --lint -f <page file>，以较低成本映射导入树。阅读页面（以及路由/后端），了解屏幕的作用、用户如何访问、它涉及的用户流程/数据，以及完整的状态列表——阅读是为了理解行为，不是为了抄录叶子节点。通过 -f 传入页面 + UI 叶子节点 + 主题（叶子节点可以只提供名称，无需阅读）；向已有屏幕的项目中添加内容时，用 @ 提及一个现有屏幕作为不得修改的参考。编写一条精确的指令，重点说明作用、关联、用户流程/状态；注明任何不得修改的范围。重新运行 mowgli edit --lint -f <all files> 并处理所有 [missing]（添加缺失项，或确认其不会绘制 UI）——不得在仍有未说明缺失叶子节点时进行编辑。之后才能运行 edit。每次调用批量处理 2-5 个简单屏幕，或 1 个复杂屏幕。
6. 阅读编辑的统计摘要；只有在结果看起来不对时才运行 diff/重新 read（无差异、文件集或行数异常、触及不得修改的文件）。如果无差异或结果有误，请重新运行。
7. mowgli -p <id> version <n> set-meta -> 记录变更、提交的短哈希，以及任何有意的偏离/省略。