InsForge 确定性跨仓库 E2E 发布门禁e2e-testing技能的实现与使用全指南【免费下载链接】InsForgeThe all-in-one, open-source backend platform for agentic coding. InsForge gives your coding agent database, auth, storage, compute, hosting, and AI gateway to ship full-stack apps end-to-end.项目地址: https://gitcode.com/GitHub_Trending/in/InsForge本文围绕 InsForge 仓库中.internal/docs/plans/2026-06-29-e2e-testing-skill.md及其配套设计文档.internal/docs/specs/2026-06-29-e2e-testing-skill-design.md展开。它讲解 InsForge 如何在 Agent 技能体系中落地一个名为e2e-testing的跨仓库发布质量门禁在 InsForge 维护者完成 OSS 仓库改动、准备提交 PR 之前先通过构建测试镜像 → 派发确定性 Fixture E2E 工作流 → 分诊失败的完整链路做一次可重复的端到端验证。读完本文你将掌握 InsForge 的 E2E 门禁如何计算测试镜像 Tag、如何判断兄弟仓库agent-e2e的 fixture 覆盖是否需要同步变更、如何用 GitHub CLI 派发并观察工作流以及失败时如何在四条可能原因之间做出正确分诊。一、为什么需要e2e-testing从本地校验通过到发布质量门禁InsForge 的insforge-dev技能集已经为维护者提供了一整套本地预检命令详见 父技能 SKILL.mdnpx turbo run typecheck # 全包通过 npx turbo run lint # 必须通过预存债务需在 PR body 中说明 npx turbo run test # 含本次改动新增的测试 npx turbo run build # 路由、配置、schema、跨包导出变更时必须执行但本地typecheck、lint、test、build只能证明代码在仓库内自洽无法证明改动在真实的部署运行时上行为正确。这正是e2e-testing技能存在的理由它是一个额外的 release-quality 门禁additional release-quality gate用于 OSS PR 提交前的确定性跨仓库 E2E 验证位于本地校验之后、PR 打开/更新/提交之前。从设计文档2026-06-29-e2e-testing-skill-design.md可以看到这一门禁的核心目标是让确定性交叉仓库 E2E 门禁在 Agent 工作流中显式且可重复explicit and repeatable任何 InsForge 改动无论由人还是由 Agent 完成都走同一条验证路径。技能边界它不做什么不替代本地校验E2E 门禁发生在本地typecheck/lint/test/build全部通过之后不随意操作兄弟仓库除非 InsForge 改动影响了确定性 fixture 覆盖应当断言的运行时行为否则不创建、不编辑本地的agent-e2e检出目录不包含探索性测试Support Desk Agent E2E (Exploratory)工作流不属于本门禁技能明确要求忽略它。二、技能架构一份规范、三处镜像、一套同步脚本e2e-testing不是单文件技能而是按 Agent 平台分面的三份镜像。按实现计划计划文档与当前仓库实际结构技能分布在平台路径当前仓库均已存在Agents规范源.agents/skills/insforge-dev/e2e-testing/SKILL.mdCodex.codex/skills/insforge-dev/e2e-testing/SKILL.mdClaude.claude/skills/insforge-dev/e2e-testing/SKILL.md三份文件逐字节一致这一点由 scripts/sync-skills.sh 保证。该脚本的头部注释L1-L18说明了设计权衡.agents/skills/insforge-dev是唯一真相源single source of truthClaude Code 与 Codex 各自从自己的目录发现技能因此需要真实拷贝而非符号链接——因为 Windows 检出不会保留符号链接会被当作纯文本文件且 Prettier 会对显式传入的符号链接报错。脚本支持两种模式scripts/sync-skills.sh # 将 .agents 规范树拷贝到 .claude 与 .codex scripts/sync-skills.sh --check # 检查三棵树是否漂移漂移则退出码非 0供 CI 使用--check模式用diff -r对比规范目录与两个拷贝目录L41-L46漂移时打印差异并提示Run scripts/sync-skills.sh and commit the result.。因此维护者的工作流是只编辑.agents/下的规范文件 → 运行scripts/sync-skills.sh→ 三个技能树一起提交。三、技能入口YAML Front Matter 与触发文本每个 SKILL.md 都以 YAML front matter 开头见 规范文件 L1-L4--- name: e2e-testing description: Use this skill when an InsForge maintainer has finished an OSS repo change and is ready to open, update, or submit the InsForge PR. Runs the release-quality deterministic E2E gate by building a package.json-derived InsForge test image tag, deciding whether sibling agent-e2e fixture coverage must change, dispatching the Deterministic Fixture E2E workflow, waiting for results, and triaging failures before PR submission. ---description是 Agent 的触发依据它浓缩了技能的四段式职责计算测试 Tag → 判断 fixture 是否需变更 → 派发确定性 Fixture E2E → 等待结果并分诊失败。正文第一句界定了使用时机Use this skill after local implementation and normal InsForge pre-PR checks pass, and before opening, updating, or submitting the InsForge OSS PR.并再次强调This is an additional release-quality gate. It does not replace localtypecheck,lint,test, orbuildvalidation from the parentinsforge-devskill.L10仓库边界约定技能明确区分两个仓库L12-L17InsForge OSS 仓库当前工作区E2E 仓库远程 GitHub 仓库InsForge/agent-e2e。关键约束工作流派发与只读检查一律使用远程InsForge/agent-e2e不依赖某个开发者特定的本地检出路径只有需要编辑确定性 fixture 测试时才创建或使用本地检出。四、工作流第一步从package.json派生测试镜像 Tag门禁的起点是构建一个确定性、可追溯的测试镜像 Tag规则L19-L39读取仓库根目录package.json的version字段当前仓库为2.3.1只递增 patch 号major/minor 不变组装为如下形式vmajor.minor.patch1-feature-or-issue-slug示例根版本2.2.3、特性storage returning rls→v2.2.4-storage-returning-rls。两个必须遵守的规则package.json是基准版本的唯一真相源计算基准时忽略已经存在的更高测试 Tag。这意味着即使镜像仓库里已有v2.3.2-xxx只要根package.json还是2.3.1本次 Tag 仍从v2.3.2-slug算起保证 Tag 与源码版本一一对应、可复现slug 清洗规则优先使用 issue key、PR 主题或分支主题全部小写连续的非字母数字字符替换为单个连字符去掉首尾连字符长度以在 GitHub Actions 和镜像 Tag 中可扫读为限。这条规则保证了同一份源码改动无论谁提交、何时提交产出的测试镜像 Tag 都是确定且可预测的这是整个确定性门禁的根基。五、工作流第二步构建并推送 InsForge 测试镜像拿到 Tag 后派发 InsForge 仓库的Build and Push Docker Image工作流L41-L56# 以测试 Tag 派发镜像构建工作流 gh workflow run Build and Push Docker Image --repo InsForge/InsForge --ref insforge-feature-branch -f test_tagtest-tag # 列出最近运行拿到 run-id gh run list --repo InsForge/InsForge --workflow Build and Push Docker Image --limit 10 # 阻塞观察指定 run gh run watch --repo InsForge/InsForge run-id三个参数的含义--repo InsForge/InsForge指定目标仓库--ref insforge-feature-branch指定从哪个特性分支构建-f test_tagtest-tag把上一节算出的 Tag 作为工作流输入由工作流负责把镜像推送到带该 Tag 的地址。硬性约束镜像构建成功之前不得启动跨仓库 E2E 工作流。这是因为 E2E 工作流的唯一输入就是insforge_tag镜像不存在时跑 E2E 只会产生无意义的失败。六、工作流第三步判断agent-e2e是否必须变更镜像构建成功后先不要急着派发 E2E而是审查 InsForge 的 diff并与InsForge/agent-e2e中的确定性 fixture 覆盖做对比L58-L72。只读检查优先走远程 GitHub 访问gh api、gh repo view、远程文件读取只有需要编辑 fixture 文件、或远程检查不足以理解覆盖情况时才使用本地检出。应当更新agent-e2e的场景当 InsForge 改动新增、移除或改变了确定性 fixture 应当断言的运行时行为时包括API 契约或校验行为认证、权限、RLS、存储、实时realtime、函数functions、定时任务schedules、AI、SDK 或 CLI 可见行为任何本地测试已覆盖、但发布门禁也应在部署运行时上保护的回归。不应当更新agent-e2e的场景内部重构internal refactors纯文档改动docs-only changes仅本地测试层面的改动确定性 fixture 已覆盖、且本次无需调整断言的改动。同时再次强调忽略Support Desk Agent E2E (Exploratory)——它不是本门禁的组成部分。这一区分把探索性 E2E与确定性门禁彻底隔离避免把不稳定、非断言的探索性结果混入发布决策。七、工作流第四步无需 fixture 变更时的直通路径若判定无需更新agent-e2e直接从agent-e2e的main分支派发确定性 fixture 工作流L74-L87# 从 agent-e2e main 派发注入 insforge_tag gh workflow run Deterministic Fixture E2E --repo InsForge/agent-e2e --ref main -f insforge_tagtest-tag # 查找并观察运行 gh run list --repo InsForge/agent-e2e --workflow Deterministic Fixture E2E --limit 10 gh run watch --repo InsForge/agent-e2e run-id--ref main意味着 fixture 验证集就是当前agent-e2e主干的确定性覆盖InsForge 侧只需用新镜像 Tag 跑一遍既有断言。这是最常见的路径多数 InsForge 改动内部重构、文档、已覆盖行为的微调并不触及对外运行时行为。八、工作流第五步需要 fixture 变更时的完整路径当 InsForge 改动确实改变了对外行为时需要走一条双 PR路径L89-L114只为了 fixture 更新才使用本地检出使用现有干净检出或把远程InsForge/agent-e2e克隆到隔离工作区git fetch origin后从origin/main出发创建分支命名为codex/short-topic只更新本次 InsForge 行为变更所需的确定性 fixture 校验器validators、fixture 数据、应用断言和文档——严格限定范围不做无关改动运行能给出信心的最小本地校验npm run typecheck npm run lint npm run fixture:e2e:dry当变更的 fixture 区域支持时再运行更广的校验broader validation 6. 为 fixture 更新打开agent-e2ePR 7.从包含 fixture 更新的agent-e2e分支派发确定性 fixture 工作流注意--ref不再是maingh workflow run Deterministic Fixture E2E --repo InsForge/agent-e2e --ref agent-e2e-branch -f insforge_tagtest-tag在推进 InsForge PR 之前观察运行结果。这条路径的价值在于agent-e2e的 fixture 更新本身也要经过本地校验与独立 PR 评审并且 E2E 运行直接从承载新断言的分支发起从而避免主干 fixture 新行为的错配。九、结果解释与失败分诊通过时L118-L122在 InsForge PR body 或最终 PR 说明中链接该次运行若需要过agent-e2ePR一并链接该 PR然后才继续打开、更新或提交 InsForge OSS PR。失败时L124-L132检查失败 job 的日志与上传的 artifact判定失败归属四选一InsForge 实现问题更新 InsForge 分支用同一个 Tag 或一个新的短重试 Tag重新构建测试镜像再重跑 E2Efixture 缺陷或断言更新缺失更新agent-e2e分支重跑本地校验再从该分支重跑 E2E瞬时基础设施问题记录证据后重跑一次无关的既有失败不归因于本次改动。铁律在确定性结果明确之前或用户明确接受风险之前不得提交 InsForge PR。这一分诊模型把谁错了与修哪里绑定在一起实现 bug 修 InsForge 分支、fixture bug 修 agent-e2e 分支、基础设施抖动重试即可杜绝了盲目重跑或改错仓库两种典型失误。十、收尾向维护者报告技能要求结束时报告固定字段L134-L142保证审计可追溯使用的测试 TagInsForge 镜像工作流运行结果agent-e2e是否发生变更Deterministic Fixture E2E运行结果InsForge PR、agent-e2ePR如有与各工作流运行的链接。这套字段正好覆盖了门禁的完整证据链镜像从哪来Tag、验证集是否变化agent-e2e 是否变更、验证结果如何run result、产物在哪里链接。十一、与父技能insforge-dev的集成e2e-testing不是孤立技能它被显式挂接在insforge-dev父技能下。在 父技能 SKILL.md 中子技能列表为- backend - dashboard - ui - shared-schemas - docs - e2e-testing ← 跨仓库发布工作流技能其中e2e-testing被单独注释为 Use the cross-repo release workflow skill when preparing an OSS PR。更关键的是父技能的Pre-PR ChecklistL60-L72它在原有的四项本地检查之后追加了第 5 项Usee2e-testingto run the deterministic cross-repo E2E gate before opening, updating, or submitting the InsForge OSS PR.这意味着任何走insforge-dev流程的 Agent在打开、更新或提交 OSS PR 之前都必须调用e2e-testing完成确定性门禁并且父技能明确禁止在改动文件的相关检查失败时推送即使 CI 之后会兜底捕获Never push with failing checks on files you touched。父技能同时给出了上下文约束L24-L46帮助 E2E 门禁的执行者理解仓库边界backend/是 API、认证、数据库、provider、realtime、schedulespackages/dashboard/是可发布的 dashboard 包frontend/是 self-hosting 模式下的本地 React Vite 壳packages/shared-schemas/是跨包契约packages/ui/是设计系统原语。这些边界正是判断改动是否影响对外运行时行为、是否需要更新 agent-e2e的依据。十二、实现计划的落地与验证闭环计划文档2026-06-29-e2e-testing-skill.md将实现拆为三个任务每个任务都有可勾选的验收步骤Task 1在三个表面创建内容一致的e2e-testing/SKILL.md正文必须覆盖 Tag 计算、镜像构建派发、确定性 fixture 派发、何时更新agent-e2e、通过/失败分诊、以及忽略 support-desk 工作流这条规则Task 2在三个表面的父insforge-dev/SKILL.md中把e2e-testing加入子技能列表并加入本地检查通过后、打开/更新/提交 OSS PR 前使用 e2e-testing的预 PR 规则Task 3验证技能 Markdown。Task 3 给出了两条可执行的验证命令L63-L71# 检查 front matter 与触发文本 sed -n 1,220p .agents/skills/insforge-dev/e2e-testing/SKILL.md sed -n 1,140p .agents/skills/insforge-dev/SKILL.md sed -n 1,140p .codex/skills/insforge-dev/SKILL.md sed -n 1,140p .claude/skills/insforge-dev/SKILL.md # 校验三份镜像逐字节一致 diff -u .agents/skills/insforge-dev/e2e-testing/SKILL.md .codex/skills/insforge-dev/e2e-testing/SKILL.md diff -u .agents/skills/insforge-dev/e2e-testing/SKILL.md .claude/skills/insforge-dev/e2e-testing/SKILL.md # CI 漂移守卫 scripts/sync-skills.sh --check预期结果子技能有合法的 YAML front matter、父技能引用e2e-testing、三份镜像子技能完全一致最后用git diff -- .agents/skills/insforge-dev .codex/skills/insforge-dev .claude/skills/insforge-dev docs/superpowers确认改动仅限新增的设计/计划文档、新的子技能文件与父技能引用。从当前仓库状态看该计划已落地三个e2e-testing/SKILL.md文件均已存在且内容一致三个父技能均已引用e2e-testingscripts/sync-skills.sh的--check模式即为计划 Task 3 的 CI 守卫实现。十三、总结一套确定、可审计、可分诊的发布门禁回顾e2e-testing技能的完整链路它的设计有四个鲜明特征确定性DeterministicTag 只由根package.json的 patch1 与 slug 派生无视已存在的更高测试 Tag保证源码与镜像一一对应fixture 覆盖固定、可断言与探索性 E2E 彻底隔离可重复Repeatable三份镜像技能 sync-skills.sh漂移守卫保证无论哪个 Agent 平台执行流程完全一致可审计Auditable强制报告字段覆盖 Tag、两次工作流结果、agent-e2e 是否变更、全部链接PR body 必须携带证据可分诊Triageable失败被严格归因为实现 / fixture / 基础设施 / 无关失败四类修复目标与重跑策略随之确定且在结果明确前禁止提交 PR。对于 InsForge 维护者与贡献者而言这条门禁把本地自洽与运行时正确之间的鸿沟用一条显式、机械、可执行的 Agent 技能补上了。它不替代本地typecheck/lint/test/build而是站在它们之上成为 OSS PR 提交前的最后一道确定性关卡。延伸阅读技能体系总览可参考 docs/agent-native/overview.mdx 与 docs/agent-native/branching.mdx仓库的本地 E2E 测试矩阵可见 tests/local/test-e2e.sh若想了解与 E2E 门禁相关的部署产物形态可对照 Dockerfile 与 docker-compose.prod.yml。【免费下载链接】InsForgeThe all-in-one, open-source backend platform for agentic coding. InsForge gives your coding agent database, auth, storage, compute, hosting, and AI gateway to ship full-stack apps end-to-end.项目地址: https://gitcode.com/GitHub_Trending/in/InsForge创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 InsForge 确定性跨仓库 E2E 发布门禁：`e2e-testing` 技能的实现与使用全指南
InsForge 确定性跨仓库 E2E 发布门禁e2e-testing技能的实现与使用全指南【免费下载链接】InsForgeThe all-in-one, open-source backend platform for agentic coding. InsForge gives your coding agent database, auth, storage, compute, hosting, and AI gateway to ship full-stack apps end-to-end.项目地址: https://gitcode.com/GitHub_Trending/in/InsForge本文围绕 InsForge 仓库中.internal/docs/plans/2026-06-29-e2e-testing-skill.md及其配套设计文档.internal/docs/specs/2026-06-29-e2e-testing-skill-design.md展开。它讲解 InsForge 如何在 Agent 技能体系中落地一个名为e2e-testing的跨仓库发布质量门禁在 InsForge 维护者完成 OSS 仓库改动、准备提交 PR 之前先通过构建测试镜像 → 派发确定性 Fixture E2E 工作流 → 分诊失败的完整链路做一次可重复的端到端验证。读完本文你将掌握 InsForge 的 E2E 门禁如何计算测试镜像 Tag、如何判断兄弟仓库agent-e2e的 fixture 覆盖是否需要同步变更、如何用 GitHub CLI 派发并观察工作流以及失败时如何在四条可能原因之间做出正确分诊。一、为什么需要e2e-testing从本地校验通过到发布质量门禁InsForge 的insforge-dev技能集已经为维护者提供了一整套本地预检命令详见 父技能 SKILL.mdnpx turbo run typecheck # 全包通过 npx turbo run lint # 必须通过预存债务需在 PR body 中说明 npx turbo run test # 含本次改动新增的测试 npx turbo run build # 路由、配置、schema、跨包导出变更时必须执行但本地typecheck、lint、test、build只能证明代码在仓库内自洽无法证明改动在真实的部署运行时上行为正确。这正是e2e-testing技能存在的理由它是一个额外的 release-quality 门禁additional release-quality gate用于 OSS PR 提交前的确定性跨仓库 E2E 验证位于本地校验之后、PR 打开/更新/提交之前。从设计文档2026-06-29-e2e-testing-skill-design.md可以看到这一门禁的核心目标是让确定性交叉仓库 E2E 门禁在 Agent 工作流中显式且可重复explicit and repeatable任何 InsForge 改动无论由人还是由 Agent 完成都走同一条验证路径。技能边界它不做什么不替代本地校验E2E 门禁发生在本地typecheck/lint/test/build全部通过之后不随意操作兄弟仓库除非 InsForge 改动影响了确定性 fixture 覆盖应当断言的运行时行为否则不创建、不编辑本地的agent-e2e检出目录不包含探索性测试Support Desk Agent E2E (Exploratory)工作流不属于本门禁技能明确要求忽略它。二、技能架构一份规范、三处镜像、一套同步脚本e2e-testing不是单文件技能而是按 Agent 平台分面的三份镜像。按实现计划计划文档与当前仓库实际结构技能分布在平台路径当前仓库均已存在Agents规范源.agents/skills/insforge-dev/e2e-testing/SKILL.mdCodex.codex/skills/insforge-dev/e2e-testing/SKILL.mdClaude.claude/skills/insforge-dev/e2e-testing/SKILL.md三份文件逐字节一致这一点由 scripts/sync-skills.sh 保证。该脚本的头部注释L1-L18说明了设计权衡.agents/skills/insforge-dev是唯一真相源single source of truthClaude Code 与 Codex 各自从自己的目录发现技能因此需要真实拷贝而非符号链接——因为 Windows 检出不会保留符号链接会被当作纯文本文件且 Prettier 会对显式传入的符号链接报错。脚本支持两种模式scripts/sync-skills.sh # 将 .agents 规范树拷贝到 .claude 与 .codex scripts/sync-skills.sh --check # 检查三棵树是否漂移漂移则退出码非 0供 CI 使用--check模式用diff -r对比规范目录与两个拷贝目录L41-L46漂移时打印差异并提示Run scripts/sync-skills.sh and commit the result.。因此维护者的工作流是只编辑.agents/下的规范文件 → 运行scripts/sync-skills.sh→ 三个技能树一起提交。三、技能入口YAML Front Matter 与触发文本每个 SKILL.md 都以 YAML front matter 开头见 规范文件 L1-L4--- name: e2e-testing description: Use this skill when an InsForge maintainer has finished an OSS repo change and is ready to open, update, or submit the InsForge PR. Runs the release-quality deterministic E2E gate by building a package.json-derived InsForge test image tag, deciding whether sibling agent-e2e fixture coverage must change, dispatching the Deterministic Fixture E2E workflow, waiting for results, and triaging failures before PR submission. ---description是 Agent 的触发依据它浓缩了技能的四段式职责计算测试 Tag → 判断 fixture 是否需变更 → 派发确定性 Fixture E2E → 等待结果并分诊失败。正文第一句界定了使用时机Use this skill after local implementation and normal InsForge pre-PR checks pass, and before opening, updating, or submitting the InsForge OSS PR.并再次强调This is an additional release-quality gate. It does not replace localtypecheck,lint,test, orbuildvalidation from the parentinsforge-devskill.L10仓库边界约定技能明确区分两个仓库L12-L17InsForge OSS 仓库当前工作区E2E 仓库远程 GitHub 仓库InsForge/agent-e2e。关键约束工作流派发与只读检查一律使用远程InsForge/agent-e2e不依赖某个开发者特定的本地检出路径只有需要编辑确定性 fixture 测试时才创建或使用本地检出。四、工作流第一步从package.json派生测试镜像 Tag门禁的起点是构建一个确定性、可追溯的测试镜像 Tag规则L19-L39读取仓库根目录package.json的version字段当前仓库为2.3.1只递增 patch 号major/minor 不变组装为如下形式vmajor.minor.patch1-feature-or-issue-slug示例根版本2.2.3、特性storage returning rls→v2.2.4-storage-returning-rls。两个必须遵守的规则package.json是基准版本的唯一真相源计算基准时忽略已经存在的更高测试 Tag。这意味着即使镜像仓库里已有v2.3.2-xxx只要根package.json还是2.3.1本次 Tag 仍从v2.3.2-slug算起保证 Tag 与源码版本一一对应、可复现slug 清洗规则优先使用 issue key、PR 主题或分支主题全部小写连续的非字母数字字符替换为单个连字符去掉首尾连字符长度以在 GitHub Actions 和镜像 Tag 中可扫读为限。这条规则保证了同一份源码改动无论谁提交、何时提交产出的测试镜像 Tag 都是确定且可预测的这是整个确定性门禁的根基。五、工作流第二步构建并推送 InsForge 测试镜像拿到 Tag 后派发 InsForge 仓库的Build and Push Docker Image工作流L41-L56# 以测试 Tag 派发镜像构建工作流 gh workflow run Build and Push Docker Image --repo InsForge/InsForge --ref insforge-feature-branch -f test_tagtest-tag # 列出最近运行拿到 run-id gh run list --repo InsForge/InsForge --workflow Build and Push Docker Image --limit 10 # 阻塞观察指定 run gh run watch --repo InsForge/InsForge run-id三个参数的含义--repo InsForge/InsForge指定目标仓库--ref insforge-feature-branch指定从哪个特性分支构建-f test_tagtest-tag把上一节算出的 Tag 作为工作流输入由工作流负责把镜像推送到带该 Tag 的地址。硬性约束镜像构建成功之前不得启动跨仓库 E2E 工作流。这是因为 E2E 工作流的唯一输入就是insforge_tag镜像不存在时跑 E2E 只会产生无意义的失败。六、工作流第三步判断agent-e2e是否必须变更镜像构建成功后先不要急着派发 E2E而是审查 InsForge 的 diff并与InsForge/agent-e2e中的确定性 fixture 覆盖做对比L58-L72。只读检查优先走远程 GitHub 访问gh api、gh repo view、远程文件读取只有需要编辑 fixture 文件、或远程检查不足以理解覆盖情况时才使用本地检出。应当更新agent-e2e的场景当 InsForge 改动新增、移除或改变了确定性 fixture 应当断言的运行时行为时包括API 契约或校验行为认证、权限、RLS、存储、实时realtime、函数functions、定时任务schedules、AI、SDK 或 CLI 可见行为任何本地测试已覆盖、但发布门禁也应在部署运行时上保护的回归。不应当更新agent-e2e的场景内部重构internal refactors纯文档改动docs-only changes仅本地测试层面的改动确定性 fixture 已覆盖、且本次无需调整断言的改动。同时再次强调忽略Support Desk Agent E2E (Exploratory)——它不是本门禁的组成部分。这一区分把探索性 E2E与确定性门禁彻底隔离避免把不稳定、非断言的探索性结果混入发布决策。七、工作流第四步无需 fixture 变更时的直通路径若判定无需更新agent-e2e直接从agent-e2e的main分支派发确定性 fixture 工作流L74-L87# 从 agent-e2e main 派发注入 insforge_tag gh workflow run Deterministic Fixture E2E --repo InsForge/agent-e2e --ref main -f insforge_tagtest-tag # 查找并观察运行 gh run list --repo InsForge/agent-e2e --workflow Deterministic Fixture E2E --limit 10 gh run watch --repo InsForge/agent-e2e run-id--ref main意味着 fixture 验证集就是当前agent-e2e主干的确定性覆盖InsForge 侧只需用新镜像 Tag 跑一遍既有断言。这是最常见的路径多数 InsForge 改动内部重构、文档、已覆盖行为的微调并不触及对外运行时行为。八、工作流第五步需要 fixture 变更时的完整路径当 InsForge 改动确实改变了对外行为时需要走一条双 PR路径L89-L114只为了 fixture 更新才使用本地检出使用现有干净检出或把远程InsForge/agent-e2e克隆到隔离工作区git fetch origin后从origin/main出发创建分支命名为codex/short-topic只更新本次 InsForge 行为变更所需的确定性 fixture 校验器validators、fixture 数据、应用断言和文档——严格限定范围不做无关改动运行能给出信心的最小本地校验npm run typecheck npm run lint npm run fixture:e2e:dry当变更的 fixture 区域支持时再运行更广的校验broader validation 6. 为 fixture 更新打开agent-e2ePR 7.从包含 fixture 更新的agent-e2e分支派发确定性 fixture 工作流注意--ref不再是maingh workflow run Deterministic Fixture E2E --repo InsForge/agent-e2e --ref agent-e2e-branch -f insforge_tagtest-tag在推进 InsForge PR 之前观察运行结果。这条路径的价值在于agent-e2e的 fixture 更新本身也要经过本地校验与独立 PR 评审并且 E2E 运行直接从承载新断言的分支发起从而避免主干 fixture 新行为的错配。九、结果解释与失败分诊通过时L118-L122在 InsForge PR body 或最终 PR 说明中链接该次运行若需要过agent-e2ePR一并链接该 PR然后才继续打开、更新或提交 InsForge OSS PR。失败时L124-L132检查失败 job 的日志与上传的 artifact判定失败归属四选一InsForge 实现问题更新 InsForge 分支用同一个 Tag 或一个新的短重试 Tag重新构建测试镜像再重跑 E2Efixture 缺陷或断言更新缺失更新agent-e2e分支重跑本地校验再从该分支重跑 E2E瞬时基础设施问题记录证据后重跑一次无关的既有失败不归因于本次改动。铁律在确定性结果明确之前或用户明确接受风险之前不得提交 InsForge PR。这一分诊模型把谁错了与修哪里绑定在一起实现 bug 修 InsForge 分支、fixture bug 修 agent-e2e 分支、基础设施抖动重试即可杜绝了盲目重跑或改错仓库两种典型失误。十、收尾向维护者报告技能要求结束时报告固定字段L134-L142保证审计可追溯使用的测试 TagInsForge 镜像工作流运行结果agent-e2e是否发生变更Deterministic Fixture E2E运行结果InsForge PR、agent-e2ePR如有与各工作流运行的链接。这套字段正好覆盖了门禁的完整证据链镜像从哪来Tag、验证集是否变化agent-e2e 是否变更、验证结果如何run result、产物在哪里链接。十一、与父技能insforge-dev的集成e2e-testing不是孤立技能它被显式挂接在insforge-dev父技能下。在 父技能 SKILL.md 中子技能列表为- backend - dashboard - ui - shared-schemas - docs - e2e-testing ← 跨仓库发布工作流技能其中e2e-testing被单独注释为 Use the cross-repo release workflow skill when preparing an OSS PR。更关键的是父技能的Pre-PR ChecklistL60-L72它在原有的四项本地检查之后追加了第 5 项Usee2e-testingto run the deterministic cross-repo E2E gate before opening, updating, or submitting the InsForge OSS PR.这意味着任何走insforge-dev流程的 Agent在打开、更新或提交 OSS PR 之前都必须调用e2e-testing完成确定性门禁并且父技能明确禁止在改动文件的相关检查失败时推送即使 CI 之后会兜底捕获Never push with failing checks on files you touched。父技能同时给出了上下文约束L24-L46帮助 E2E 门禁的执行者理解仓库边界backend/是 API、认证、数据库、provider、realtime、schedulespackages/dashboard/是可发布的 dashboard 包frontend/是 self-hosting 模式下的本地 React Vite 壳packages/shared-schemas/是跨包契约packages/ui/是设计系统原语。这些边界正是判断改动是否影响对外运行时行为、是否需要更新 agent-e2e的依据。十二、实现计划的落地与验证闭环计划文档2026-06-29-e2e-testing-skill.md将实现拆为三个任务每个任务都有可勾选的验收步骤Task 1在三个表面创建内容一致的e2e-testing/SKILL.md正文必须覆盖 Tag 计算、镜像构建派发、确定性 fixture 派发、何时更新agent-e2e、通过/失败分诊、以及忽略 support-desk 工作流这条规则Task 2在三个表面的父insforge-dev/SKILL.md中把e2e-testing加入子技能列表并加入本地检查通过后、打开/更新/提交 OSS PR 前使用 e2e-testing的预 PR 规则Task 3验证技能 Markdown。Task 3 给出了两条可执行的验证命令L63-L71# 检查 front matter 与触发文本 sed -n 1,220p .agents/skills/insforge-dev/e2e-testing/SKILL.md sed -n 1,140p .agents/skills/insforge-dev/SKILL.md sed -n 1,140p .codex/skills/insforge-dev/SKILL.md sed -n 1,140p .claude/skills/insforge-dev/SKILL.md # 校验三份镜像逐字节一致 diff -u .agents/skills/insforge-dev/e2e-testing/SKILL.md .codex/skills/insforge-dev/e2e-testing/SKILL.md diff -u .agents/skills/insforge-dev/e2e-testing/SKILL.md .claude/skills/insforge-dev/e2e-testing/SKILL.md # CI 漂移守卫 scripts/sync-skills.sh --check预期结果子技能有合法的 YAML front matter、父技能引用e2e-testing、三份镜像子技能完全一致最后用git diff -- .agents/skills/insforge-dev .codex/skills/insforge-dev .claude/skills/insforge-dev docs/superpowers确认改动仅限新增的设计/计划文档、新的子技能文件与父技能引用。从当前仓库状态看该计划已落地三个e2e-testing/SKILL.md文件均已存在且内容一致三个父技能均已引用e2e-testingscripts/sync-skills.sh的--check模式即为计划 Task 3 的 CI 守卫实现。十三、总结一套确定、可审计、可分诊的发布门禁回顾e2e-testing技能的完整链路它的设计有四个鲜明特征确定性DeterministicTag 只由根package.json的 patch1 与 slug 派生无视已存在的更高测试 Tag保证源码与镜像一一对应fixture 覆盖固定、可断言与探索性 E2E 彻底隔离可重复Repeatable三份镜像技能 sync-skills.sh漂移守卫保证无论哪个 Agent 平台执行流程完全一致可审计Auditable强制报告字段覆盖 Tag、两次工作流结果、agent-e2e 是否变更、全部链接PR body 必须携带证据可分诊Triageable失败被严格归因为实现 / fixture / 基础设施 / 无关失败四类修复目标与重跑策略随之确定且在结果明确前禁止提交 PR。对于 InsForge 维护者与贡献者而言这条门禁把本地自洽与运行时正确之间的鸿沟用一条显式、机械、可执行的 Agent 技能补上了。它不替代本地typecheck/lint/test/build而是站在它们之上成为 OSS PR 提交前的最后一道确定性关卡。延伸阅读技能体系总览可参考 docs/agent-native/overview.mdx 与 docs/agent-native/branching.mdx仓库的本地 E2E 测试矩阵可见 tests/local/test-e2e.sh若想了解与 E2E 门禁相关的部署产物形态可对照 Dockerfile 与 docker-compose.prod.yml。【免费下载链接】InsForgeThe all-in-one, open-source backend platform for agentic coding. InsForge gives your coding agent database, auth, storage, compute, hosting, and AI gateway to ship full-stack apps end-to-end.项目地址: https://gitcode.com/GitHub_Trending/in/InsForge创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考