企业官网建设流程全解析

Plate Slate v2 行为门禁：slate-ar-gate 测量型 Gate 循环的边界、命令与交接规范

【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate

在 Plate 仓库中推进 Slate v2 重写时，一个高频问题是："这块已有的行为证明面（proof surface）能不能稳定重复通过？失败证据到底说明什么？".agents/skills/slate-ar-gate/SKILL.md定义的回答就是一套测量型 Gate 循环：反复执行既有的测试、类型检查、浏览器与编辑器行为门禁，记录耗时与通过状态，但不负责设计缺失的测试，也不负责修复正确性缺陷。读完本文，你可以掌握该 Gate 循环的职责边界、日志状态机、完整的 CLI 命令序列与全量编辑器行为验证命令，并理解它与仓库中其它自动化通道（slate-patch、slate-plan、slate-ar-perf等）之间的路由关系。

定位：只回答"能否重复通过"，不设计缺失的 Oracle

slate-ar-gate是一份 Agent 技能定义（Skill），其源文件同时存在于 skills 目录 与 rules 目录，两处内容一致，后者是 skiller 工具生成的 source（见 skills 文件头部的metadata.skiller.source字段）。

文档对使用场景的界定非常克制——它回答的唯一问题是：

"Can this existing proof surface pass repeatably, and what does the failure evidence say?"

它适用于完整的编辑器行为测试，覆盖以下行为面（behavior surfaces）：

• 光标导航（navigation）与输入（typing）
• 选区（selection）与剪贴板（clipboard）
• IME、焦点（focus）、撤销/重做（undo/redo）
• 浏览器路由、包级测试、bun check
• 聚焦的 Playwright 套件

但有一个硬性前提：门禁命令必须已经存在或显而易见（"the gate command must already exist or be obvious"）。如果一个行为面连可执行的断言都没有，就不属于slate-ar-gate的管辖范围——这类缺失 Oracle 的设计工作要路由给testing、tdd、editor-test-harvester或slate-patch。

职责边界：Gate 拥有什么、不拥有什么

原文档用一个 Boundary 小节把职责切得很干净，整理成表如下：

边界中还有一条重要的止损规则：不要让一个失败的门禁无限空转——

Do not spin a failing gate forever. If a gate fails twice with the same behavioral signal and the command shape is valid, route toslate-patch.

即：当门禁两次以相同的行为信号失败、且命令形态本身有效时，说明问题大概率出在编辑器行为本身而非门禁执行，此时应停止重复测量，把证据交给slate-patch去修复。这条规则把"测量者"和"修复者"两个角色彻底分开，是这套循环不会陷入死循环的关键。

循环配置：指标方向与五种日志状态

Gate 循环建立在通用 Autoresearch 引擎之上。默认指标是耗时秒数（elapsed seconds），越低越好。对布尔型行为门禁（通过/失败），指标只记录运行时长，真正的结论由日志状态承载。原文档定义了五种状态，构成一个简单的状态机：

这个设计与 Slate v2 的总原则一致：slate-ar 技能文档 明确写道 "Slate correctness beats local metric movement"——一个破坏了编辑器行为的 packet 只能是checks_failed或discard，绝不可能是keep，哪怕它的耗时指标更好看。

命令序列：setup-plan 到 log 的完整流程

对于显式的门禁命令，原文档给出如下 CLI 序列（<autoresearch-cli>是占位符，表示 Autoresearch CLI）：

<autoresearch-cli> setup-plan --cwd .tmp/slate-v2 --name "<gate-name>" --metric-name "seconds" --benchmark-command "<gate command>" --benchmark-prints-metric false --checks-command "<gate command>" <autoresearch-cli> doctor --cwd .tmp/slate-v2 <autoresearch-cli> serve --cwd .tmp/slate-v2 <autoresearch-cli> next --cwd .tmp/slate-v2 <autoresearch-cli> log --cwd .tmp/slate-v2 --from-last --status measure --description "<gate result>"

各参数值得展开说明：

• --cwd .tmp/slate-v2：循环状态落在仓库内的.tmp/slate-v2工作目录。注意这不是 Plate 产品代码本身——slate-ar 技能 指出.tmp/slate-v2是 Slate v2 工作区的目标 cwd，活跃循环状态存放在.tmp/slate-v2/autoresearch.*与.tmp/slate-v2/autoresearch.research/**中；
• --metric-name "seconds"：指标名固定为秒数；
• --benchmark-command与--checks-command：对布尔门禁二者相同，即同一个命令既产生耗时指标又产生通过/失败判定；
• --benchmark-prints-metric false：声明该命令的标准输出里不直接打印指标数值，指标由引擎以耗时方式采集；
• doctor：环境自检；serve：启动 dashboard 服务；next：推进循环取下一步；log --from-last --status measure：把最近一次执行按measure状态记录进循环日志。

从源码结构看，仓库为这条命令链提供了本地包装脚本 tooling/scripts/slate-autoresearch.mjs：它把slateV2Cwd固定为.tmp/slate-v2，并在未显式传--cwd时自动注入该参数，然后把子命令转发给同级codex-autoresearch仓库中的autoresearch.mjs脚本。也就是说，上表中的<autoresearch-cli>在本仓库语境下可以落地为node tooling/scripts/slate-autoresearch.mjs。该脚本还提供suggest-loops/recommend-loops子命令（见 建议循环入口），基于.tmp/slate-v2的当前 Autoresearch 状态与最新基准产物生成按优先级排序的循环建议——这正是 Gate 循环"选哪个证明面来跑"的上游决策来源。

全量编辑器行为验证：先聚焦，再放大

对完整编辑器行为的证明，原文档要求先用一条聚焦命令，然后再逐步放大，给出三级递进的命令形态：

cd .tmp/slate-v2 bun check bun check:full PLAYWRIGHT_BASE_URL=http://localhost:3100 PLAYWRIGHT_RETRIES=0 PLAYWRIGHT_WORKERS=1 bun playwright playwright/integration/examples/<suite>.test.ts --project=chromium

三级含义：

1. bun check：快速门禁，对应工作区内的 lint / typecheck / 测试组合。作为参照，Plate 仓库根 package.json 中定义的check脚本是pnpm lint && pnpm typecheck && pnpm test:all && pnpm test:slowest的完整门禁链，check:push则去掉test:slowest——Slate v2 工作区内的bun check/bun check:full承担的是同构角色（快速档与全量档）；
2. bun check:full：全量检查，作为聚焦命令通过后的第二道闸门；
3. Playwright 单套件命令：只跑一个行为面套件，环境变量各有明确目的：
   • PLAYWRIGHT_BASE_URL=http://localhost:3100：把测试目标指向 Slate v2 工作区自己的开发服务器端口（3100），而非 Plate 主站的默认端口；
   • PLAYWRIGHT_RETRIES=0：门禁测量下禁止重试掩盖抖动——flake 必须被看见并被记录，而不是被重试抹平；
   • PLAYWRIGHT_WORKERS=1：单 worker 串行执行，排除并行干扰，保证每次测量在相同并发条件下可比；
   • --project=chromium：只跑 Chromium 项目。仓库的 Playwright 配置 tooling/config/playwright.config.ts 同时定义了chromium、firefox、webkit三个项目，且本地默认retries: 0、CI 下才为 2——与门禁命令显式压住重试、并行度的一致性意图吻合。

文档还要求：当完整套件对当前证明来说过于宽泛时，必须把刻意跳过的行为家族（behavior families）记录在案。这把"少跑了什么"变成了一等公民的交接信息，避免后续把"没跑"误读成"跑了且通过"。

交接（Handoff）：Gate 结束时必须报告什么

循环的出口是一份结构化交接报告，原文档列出六项必报内容：

1. 实际执行的门禁命令；
2. 通过/失败状态；
3. packet 计数（对应keep/discard/crash/checks_failed各状态的数量）；
4. 重复失败签名（repeated failure signature）——两次以上失败是否呈现相同行为信号；
5. dashboard URL（若serve已启动）；
6. 下一个所有者（next owner）：继续 Gate（continue gate）、转slate-patch（修正确性）、转slate-plan（改设计），或转slate-ar-perf（正确性已稳，开始速度优化）。

这六项合起来构成一个可审计的决策链：命令形态有效 + 同签名失败两次 →slate-patch；门禁稳定 →slate-ar-perf；证明面缺失 → 回到 Oracle 设计侧。

小结

slate-ar-gate的价值在于把"重复执行既有证明"这件容易无限空转的事约束成一个有指标、有状态机、有止损规则、有明确交接格式的小型测量循环：它只测量、不设计、不修复，所有越界情形都有唯一路由出口（slate-patch/slate-plan/slate-ar-perf/ Oracle 设计侧）。结合 slate-ar 总控技能 中的默认约定（目标 cwd、Slate 正确性优先于局部指标、packet 计数纪律），以及 slate-autoresearch 包装脚本 提供的本地 CLI 落地，这套 Gate 循环构成了 Plate 仓库在 Slate v2 重写过程中验证"编辑器原生行为不回归"的核心基础设施。

【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate