plate

/plate

Plate 会在评审前完成本地工作。它会补齐所需产物、进行验证、安全地提交，并选择正确的发布路径。

阶段入口

运行 python3 skills/plate/scripts/plate.pyz wheypoint-resolve --ref <slug>。 authoritative 使用记录；其 working_context 是首个批量 tilth_read。 not-found 会冷启动继续；legacy 会显示其来源和 slug，然后继续。 遇到 gated、ambiguous 和 error 时停止并显示载荷。 显示 stale-commit 和 grounded-path-missing 提示性问题。

Plate 会解析 slug 并读取结果，但不会提交 wheypoint 修订，也不会发布 wheypoint 修订。

路由规则

选择模式前先检查归属。 /plate 负责暂存、提交、推送、普通拉取请求变更和拉取请求堆栈变更。

• /plate 绝不执行代码质量评审，也绝不为了自身目的计算评审范围。评审应使用 /age。
• GitHub 检查、评审、评论、CI、合并、议题、工作流、发布、搜索和管理不属于 /plate 的职责范围。 无需本地发布事务时，直接使用 gh CLI。 对拉取请求反馈或 CI 失败采取行动时，使用 /affinage。
• 仅仅读取或评估 GitHub 或差异状态的请求，在选择任何模式前都应离开 /plate。 因此，将此类请求路由到这里属于 /plate 的错误。
• 删除、重写历史、不安全的强制推送和修改受保护分支都需要用户明确授权。

先分类，再加载一个参考文档

将每次调用准确归类为一种模式。每次只加载一个参考文档，不要读取其他文档。

模式	触发条件	加载
仅提交	保存本地工作，不发布	references/durable-writes.md
拓扑预检	在其他工作流创建提交或分支之前，持久化新的 PR 布局	references/topology.md
新建 PR	此分支没有现有 PR，且请求发布	references/topology.md
现有 PR	更新 PR，同时保留其当前拓扑	references/ordinary-pr.md
堆栈维护	创建、同步、重新堆叠、提交、恢复或明确发布堆栈	references/stacks.md

仅在执行已请求的堆栈变更时检查堆栈。若请求只是检查堆栈，且未请求任何变更，则应将其路由出 /plate，改用 gh CLI。

新建 PR 工作按以下顺序加载参考文档。每次单独加载一个。关闭当前文档后再加载下一个。

1. 加载 references/topology.md。确定拓扑。由 Plate 决定，不询问用户。
2. 对于 single 或 orthogonal_flat 形态，加载 references/ordinary-pr.md。对于堆叠形态，加载 references/stacks.md。
3. 对于堆叠形态，从 references/stacks.md 中准确加载一个提供方参考文档。 提供方参考文档包括 gt.md、git-town.md 和 gh-stack.md。 若没有可用的提供方，references/stacks.md 会转到 setup.md。

当现有拉取请求使用堆栈时，加载 references/stacks.md。不要直接进行单分支推送。

硬性门槛

接受 --hard，在首次分享工作供审核之前立即运行 /hard-cheese。 向该门槛提供一个 JSON 上下文。其中包括最终产物清单、完成情况各行、已跟踪产物差异摘要和质量门禁结果。 不要向它提供较早的实现快照。

读取门禁状态。然后应用以下矩阵：

门禁状态	响应
PASS	继续发布
LOGGED	继续发布。将记录的问题写入拉取请求正文
ERROR	发布前询问用户。报告门禁错误
FAILED	停在 quality gate 阶段。不要发布。修复工作

通过共享提问传输机制提出 ERROR 问题。 参见 ../cheese/references/ask-user-question.md。

工具路由

• 选择堆栈提供程序之前，先运行 python3 skills/plate/scripts/plate.pyz stack-tools。 该命令会检测 Graphite、Git Town 和 gh stack。它不会更改仓库状态。
• 使用 Git 和 GitHub 管理仓库、远程仓库和 PR 状态。使用所选提供程序 CLI 管理堆栈状态。
• 使用仓库的代码智能后端编辑已跟踪产物。使用同一后端读取这些产物。 使用 code-intelligence-routing.md 选择后端。 按照 references/durable-writes.md 中的顺序操作：新鲜的带标签读取、一次防过期写入、差异回读。 使用具名路径。不要使用 shell 重定向。
• 通过 /wiki-ingest 发送持久化的 Wiki 知识。不要直接编辑 Hallouminate 树。
• 将临时完成情况文件和 PR 正文文件保存在 .cheese/ 下。不要暂存这些文件。
• 斜杠命令是宿主环境的呈现形式，不是控制模型。展示宿主环境示例前，先说明所需能力。 参见 ../cheese/references/harness-portability.md。

通用事务

仅提交的工作和普通 PR 工作使用此事务。堆栈式工作使用 references/stacks.md 中的逐层事务。

1. 最终写入门槛 — 列出每项承诺或要求的产物。写入每项产物。回读每项产物。 遵循 references/durable-writes.md。如果缺少或未验证任何必需写入，则停止。
2. 验证 — 运行仓库的质量门禁。在 easy-cheese 或任何定义了 just check 的仓库中使用 just check。 质量门禁失败时，不要提交或发布。
3. 检查 — 查看状态、完整差异和近期日志。验证预期的文件集。
4. 暂存 — 仅添加具名文件。不要暂存整个树。 保持临时 .cheese/ 报告未暂存。包含已跟踪的 Wiki 和文档更改。 如果仓库有 Hallouminate Wiki，请检查 git status 中未提交的 .hallouminate/wiki/ 路径。 包含本次会话中较早写入的内容。除非 Git 忽略这些写入，否则将其暂存。 使用此事务发布 Wiki 更新。不要稍后再发布。
5. 提交 — 使用说明原因的 Conventional Commit 消息。除非用户要求，否则不要 amend。 不要绕过钩子。
6. 验证 — 检查状态和已提交的文件集。
7. 按要求发布 — 遵循 references/ordinary-pr.md。发布后读取 PR 并进行验证。

仅提交模式在验证后停止。它不会推送或创建 PR。

提交约定

暂存前，检查 git status、完整差异和近期提交。 拒绝凭据、.env 文件和无法说明的大型二进制文件。明确暂存每个预期路径。 使用以下格式：

type(scope): short description

Optional body when the rationale needs it.

先写主题。语气保持中性。主题中先说明变更。 可选正文中只写审核者需要了解的事实。正文应简短。省略叙述性文字、语气描述和俚语。

使用以下类型：feat、fix、refactor、chore、docs、test 和 style。 如果钩子失败，修复失败原因。产物发生变化时，重新运行写作和质量门禁。 重新暂存每个指定文件。创建新提交。

多行提交消息使用单引号 heredoc 分隔符。此分隔符可防止反引号和美元符号被 shell 插值。 如果项目接受 harness 身份，可选择使用 Co-Authored-By: <name> <email> 尾注。否则，省略该尾注。 暂存后，检查缓存差异。工作区差异为空，可能意味着所有更改都已暂存。 读取缓存差异，以区分这种状态和没有更改的情况。

每个审核单元创建一个提交。单个 PR 创建一个提交，每个堆栈层创建一个提交。 不要为了逐个提交审核而调整 PR。系统不会跟踪每个提交的审批状态。 质量门禁通常只在分支顶端运行。对一个提交的反馈会延误其他提交。 仅当一系列简单步骤较短时，才在一个 PR 中使用多个提交。合并后的更改应保持较小。

停止处理

每次停止都要说明模式、失败步骤以及由谁负责。 步骤名称必须且只能是以下之一：classify、topology、durable write、quality gate、stage/commit、publish 或 terminal validation。 在停止和完成报告中，遵循 ../age/references/voice.md 中的共享语气规则。

• Plate-owned — 此技能选择了错误的调用形式或路由。 例如，写入格式错误、写入内容过时、跳过读取或暂存路径未命名。 使用全树暂存路径也属于 Plate-owned。模式与参考不匹配也属于 Plate-owned。 针对 /age 的审核工作或发布之外的 GitHub 工作，属于 Plate-owned 路由错误。 使用以下恢复规则：修正调用形式或路由，然后重试该步骤
• Environment-owner — 失败由身份验证、权限、钩子、网络、提供方启用状态或共享后端导致。 在报告中指出负责的系统。切勿将其当作调用形式错误来重试。 此外，切勿通过放宽门禁、暂存未命名路径或跳过回读来绕过失败。

质量门禁失败表明工作尚不可交付。因此，应在 quality gate 阶段停止。然后修复工作。

完成

将最终证据写入临时 JSON 文件。 运行 python3 skills/plate/scripts/plate.pyz validate-publication <state.json>。 只有当命令返回包含 valid: true 的规范化证据时，才报告完成。

{
  "mode": "new-pr",
  "topology": "single",
  "provider": "ordinary",
  "artifacts": [
    {"target": "docs/adr/example.md", "backend": "tilth", "verified": true}
  ],
  "gate": {"command": "just check", "result": "pass"},
  "commits": ["0123456789abcdef0123456789abcdef01234567"],
  "pr_plan": {
    "contract_version": {
      "schema_uri": "https://schemas.easy-cheese.dev/pr-plan",
      "major": "1",
      "minor": "0"
    },
    "shape": "single",
    "target_branch": "main",
    "groups": [
      {
        "branch": "feature",
        "title": "docs: example ADR",
        "base": "main",
        "commits": ["0123456789abcdef0123456789abcdef01234567"],
        "depends_on": []
      }
    ]
  },
  "prs": [
    {
      "url": "https://github.com/example/repo/pull/42",
      "base": "main",
      "head": "feature",
      "verified": true
    }
  ],
  "risk": "none"
}

所选模式不创建提交或 PR 时，使用空的 commits 或 prs 列表。 拓扑预检会在发布事务和质量门禁之前停止。 因此，拓扑预检应使用 gate: {"command": "n/a", "result": "n/a"}。

请参阅 references/commands.md 中生成的工具包命令清单。