fcode-code-validation

Factorial Code — 应用验证

在请求发布之前，在本地运行的发布前检查，用于验证平台自身的发布标准（标准见 fcode-ama references/journey.md §8），并补充人工审核人员会检查的维度：表单与生命周期、国际化、日志规范、安全性、邮件滥用。

同一套流程服务于两类受众：请求发布前进行自查的应用开发者，以及负责审核并决定是否放行的平台代理审核人员。无论哪种情况，输入都是工作区（“团队”）标识，输出都是克隆工作区中的 APP_VALIDATION_REPORT.md，以及聊天中的 ✅/❌ 判定。

此技能仅负责流程、检查目录、严重性级别和报告格式。它检查的每条规则都由其他技能负责，并在目录行中标明来源——若某条检查结果需要上下文，请阅读对应的来源技能。

注意事项

• 本次审核为只读。 唯一允许的写入操作是克隆工作区本身和创建 APP_VALIDATION_REPORT.md。绝不要执行 fcode push、--force、settings:versions:create / settings:aliases:set，绝不要编辑工作区文件，也绝不要执行 fcode add 添加报告。
• 审核期间绝不要执行 fcode run。 进程可能会使用从父工作区继承的凭据调用真实 API（fcode-core-concepts）。这是对代码和配置进行的静态审核。
• 克隆标识是经过编码的 dev-… 令牌，不是浏览器 URL 中的应用 UUID——请从应用 Development 标签页中的“How to build locally”指南复制（参见 fcode-cli）。UUID 格式的标识无法克隆。
• 任何 Blocker → ❌。 Warning 和 Suggestion 不会改变判定结果。
• 存在歧义时必须暂停审核。 如果用户指定的开发团队中有多个应用，或无法确定要审核哪个工作区（dev- / deploy- / prod-），请列出候选项并先询问用户，再进行克隆。通常应审核 dev-。
• 拉取的变量中出现 ******** 占位符是正常的——被遮蔽的密钥不算问题，审核也不需要真实密钥值。绝不要索要这些值。
• fcode clone 失败时，通常是 UUID 混淆或缺少访问权限——请指向 fcode-ama 中的权限申请流程；不要盲目重试。
• 混合使用 JS/Python 的工作区没有问题——按照各自语言的规则审核每个进程，并在报告标题中注明混合使用情况。
• 只审核工作区自身拥有的内容。 继承的资源——来自 parentTeams 父级团队的模块、进程和变量，以及 variables.inherited.env、i18n/<locale>.inherited.yaml——在其所属工作区发布时已完成验证。不要审核这些资源的内容；发现项只能涉及当前工作区对它们的使用方式。

严重性模型

严重性	含义	对判定结果的影响
Blocker	导致运行时故障、凭据处理不当、平台邮件域名遭到滥用，或未通过平台发布门槛检查的标准	任意一项 → ❌
Warning	违反已记录的规则；预计会遭到审核人员质疑，或导致未来故障	仅供参考
Suggestion	符合平台惯例的改进建议	仅供参考

流程

1. 解析工作区。 确认 slug 是经过编码的令牌（参见 注意事项），并确定工作区类型；必要时与用户确认以消除歧义。在报告标题中记录类型。
2. 获取。 如果缺少 CLI：先询问用户，然后运行 pnpm install -g @factorialco/fcode-cli——这是唯一允许的安装操作。 获取全新副本：fcode clone <workspace-slug> --skipSkillsSetup。 已克隆：运行 fcode pull；若存在分歧，绝不使用 --force——询问用户是否按当前状态检查本地内容，并在报告标题中记录答复。
3. 盘点（只读）。通过每个流程检测语言（index.js 对比 main.py）。列出流程、模块、appRole，以及各个 processes/<slug>/metadata.json 中的 webhook/表单设置；读取 settings.json、三个变量文件、variables.meta.json 和 i18n/。运行 fcode status、fcode variables:status、fcode settings:status 和 fcode i18n:status。盘点过程中区分自有资源与继承资源——目录仅适用于自有资源（参见注意事项）。
4. 运行检查目录。 阅读 references/checks.md，根据盘点结果评估每项检查，并记录 file:line 证据。 第 2 步是全新克隆还是使用预先存在的本地工作区，将决定 STRUCT 布局检查是完整执行，还是标记为 “N/A — fresh clone”。
5. 分类。 应用目录中每一行对应的严重级别；仅在该行允许时才可偏离，并在发现项中说明原因。
6. 编写报告至 <workspace>/APP_VALIDATION_REPORT.md，遵循 references/report-template.md，覆盖之前运行生成的报告。
7. 在聊天中打印结论：✅/❌ 行、各严重级别的数量，以及 Blocker 标题。

检查类别

STRUCT · LANG · FORM · I18N · SEC · MAIL · REUSE · LOG · LIFE · REL——完整目录、各项检查的严重级别及所有者引用见 references/checks.md。