fix: harden template publishing validation

[xiongxz]

Summary

• reject native publishing metadata when framework, lockfile, package manager, dependencies, or build script do not match the controlled build profile
• require every non-native template to provide an actionable publishing blocker
• reject contradictory build profiles and blockers before template changes merge

Validation

• npm test
• npm run validate
• built and admitted every native template: admin-dashboard, insight-flow-agent-chat, web-research-agent, website-change-monitor, react, todo

[xiongxz]

Review（首轮）

先说结论：校验逻辑本身没问题，registry 现有 11 条全过；但新加的那条「矛盾 build profile」测试在旧代码上也是绿的，没有真正锁住新增的检查；另外这边的门比平台侧（insforge-platform#82）少三类检查，会出现「模板仓库 CI 绿、平台同步却拒」。

已核实的事实

• 本分支 npm test 19/19、npm run validate 11 个模板 OK。
• 把本 PR 的测试文件原样拿到 main 的 validate-registry.mjs 上跑：18/19 通过，只有 rejects non-native templates without an actionable blocker 一条红。

P2 · rejects a native build profile that contradicts the framework or source 是假绿

用例把 fixture good-slug（没有 lockfile、package.json 只有 {}）声明成 nextjs + native + vite-npm-v1，然后用 /incompatible|required|build script/i 匹配。但 main 对这个 fixture 本来就会报：

good-slug/package-lock.json: required by vite-npm-v1
good-slug: build script is not allowed by vite-npm-v1

required 和 build script 都命中，所以新增的框架/依赖/反向 lockfile/packageManager 四条检查删掉，测试照样过。建议二选一：

1. 断言收紧到新消息本身：/incompatible with framework nextjs/ 和 /requires a Vite dependency/；
2. 更好：加一个带 package-lock.json 和合法 build: "vite build" 的 fixture，让旧检查全部安静，只剩新检查发声。反向 lockfile 冲突和 packageManager: "yarn@…" 两条目前也没有任何用例覆盖。

P2 · 与平台侧导入门不对齐

insforge-platform#82 在同一时刻加的 validatePublishingSourceContract 对 native 模板还会拒绝：

• package.json 生命周期脚本：preinstall/install/postinstall/prepublish/prepublishOnly/preprepare/prepare/postprepare/prebuild/postbuild 任一非空；
• workspaces 非空；
• next-static-*：next.config.* 必须有 output: export，且不能有 app/api、pages/api、middleware.*、'use server'、next/headers、cookies()/headers()。

这三类本脚本都没查。PR 描述说目标是「reject … before template changes merge」，现在的形态是：一个带 prepare: husky 的 native 模板在这里绿，合进 main 后平台同步时该条目变成 Failed。建议把这三类照抄过来（平台那边就几十行，逻辑可以一一对应），尤其 next-static 那组今天就有对象：todo 在平台 starterEntries 里是 next-static-npm-v1。

顺带说明：react / todo / nextjs 三个目录这里根本没校验

它们不在 registry.json 里（条目由平台 starterEntries 补），所以 npm run validate 不会碰这三个目录。PR 描述里「built and admitted … react, todo」是平台同步的结果，不是本脚本的结果。要么把它们加进 registry.json，要么在描述里说清楚校验边界。

nit

• native 分支在 package.json 缺失时会在 package.json: missing 之外再连报 4 条（依赖、build script…），可以在 pkg 为空时提前返回，减少噪音。

[xiongxz]

已处理首轮 review：1) 将 framework 测试改为完整合法 Vite fixture，并精确断言新错误，消除假绿；2) 新增双 lockfile、错误 packageManager、lifecycle、workspaces、Next runtime-only 源码测试；3) 仓库校验已与 Platform 对齐 Next output: export/API routes/middleware/server APIs；4) 将平台补充的 react/todo/nextjs 三个内置合同纳入 publishing-only 校验；5) package.json 缺失时不再产生依赖/脚本连带噪音。当前 22 tests passed，registry + built-ins 共 14 个合同通过。更新 head: f2c66e7。

[xiongxz]

Review（二轮）— 不挡合并，余一条测试缺口

首轮三条全修，且修得比我提的更完整（内置三个 starter 也纳入了 publishing-only 校验）。

复核结果（head f2c66e7）

• npm test 22/22，npm run validate 14 个合同 OK（registry 11 + 内置 react/todo/nextjs）。
• 假绿已消除：rejects a native build profile that contradicts the framework or source 现在用带 lockfile + 合法 build script 的临时 fixture，并精确断言 vite-npm-v1 is incompatible with framework nextjs。
• 逐条 mutation（每次只删一个检查再跑全套）：

删掉的检查	结果
vite 框架不兼容	红 ✅
生命周期脚本循环	红 ✅
workspaces	红 ✅
反向 lockfile 冲突	红 ✅
Next 运行时源码扫描	红 ✅
output: export 检查	22 全绿 ❌

P3 · Next.js static publishing requires output: export 没有测试覆盖

上表最后一行：把 if (!NEXT_STATIC_EXPORT_PATTERN.test(configs)) … 整行删掉，22 条测试照样全过。现有 rejects Next.js static profiles with runtime-only source 的 fixture 带了 output: 'export'，只测了 api 路由那一支。补一个 fixture：next.config.ts 写成 export default {}、无 api 路由，断言 /requires output: export/。顺手也可以让 validates publishing contracts for platform-provided starter entries 那条不只是断言无错，至少对 todo 断言它是走了 next-static 路径（否则将来 todo 从 BUILT_IN_PUBLISHING_CONTRACTS 里掉了也没人知道）。

不挡合并的观察

• BUILT_IN_PUBLISHING_CONTRACTS 是平台 internal/templatecatalog/sync.go 里 starterEntries() 的手抄副本，两边没有任何机制保证同步。建议在常量上方加一行注释指向平台那个函数，改动时人能对上。
• Next 运行时扫描的文件面比平台小：这里只扫 platformAISourceFiles 的源码扩展名，平台 nextStaticBlockers 扫 bundle 里所有文件（含 .md/.sql/.css）。今天的模板没有踩到（我 grep 过 todo/README.md 和 migrations，没有 cookies(/headers(），只是记一下方向：这回是平台更严。
• CI 里 Native template build and artifact admission 我看时还在 pending，以它跑完为准。

[xiongxz]

已处理二轮 review（head 4dd9714）：

• 新增独立测试：Next static profile 缺失 output: export 必须失败，补上 mutation 发现的唯一测试缺口。
• built-in contract 测试明确断言 todo 仍是 nextjs + next-static-npm-v1 + native。
• 常量上方注明需与 Platform starterEntries() 保持同步。
• Next runtime 扫描覆盖模板内全部文件（排除构建产物/依赖目录），与 Platform 扫描范围一致。

本地验证：23/23 tests passed；14 个 publishing contracts 通过；git diff --check 通过。新一轮 CI 正在运行。

[xiongxz]

Review（三轮）— LGTM，可合

二轮唯一的 P3 已补上，其余三条观察也都落地了。

复核结果（head 4dd9714）

• npm test 23/23，npm run validate 14 个合同 OK，CI 四个 job 全绿（含 Native template build and artifact admission）。
• output: export 缺口已闭合：删掉 if (!NEXT_STATIC_EXPORT_PATTERN.test(configs)) … 这一行，rejects Next.js static profiles without output export 变红，23 → 1 failed。
• todo 合同被钉住：把 BUILT_IN_PUBLISHING_CONTRACTS 里 todo 改成 requires-node-runtime，validates publishing contracts for platform-provided starter entries 变红。以后内置合同漂移会被抓到。
• 常量上方已注明与平台 starterEntries() 对齐。
• Next 运行时扫描改为全文件（排除构建产物/依赖目录），探针：native next-static fixture 的 README.md 里写一句 Call `headers()` 会被判 requires a Node runtime。这和平台 nextStaticBlockers 的行为一致，两边现在同松同严。

不挡合并的一句话

上面那个 README 探针也说明：文档里的一句 prose 现在会让 native next-static 模板过不了门，而且两边一起拒。这是既有正则的固有毛病（\bheaders\s*\( 不分代码和文字），不是本 PR 引入的，只是随扫描面扩大而更容易踩到。将来 next-static 模板多起来再考虑把扫描面收回源码扩展名，或者给正则加个「只看代码文件」的限定，两边同步改。