forge-app-review

Forge 应用审查

执行一次通用的 Forge 发布就绪审查。此技能是广泛应用审查的入口，不能替代专业的安全、成本或调试技能。

边界

使用此技能的场景：

• 部署前和发布就绪检查。
• 通用架构和可维护性审查。
• Manifest/模块/资源/函数接线。
• 运行时、依赖、包和脚本健全性检查。
• 基本测试/部署就绪性和运维卫生。
• 明显的安全、成本或可靠性异味，应触发更深入的专业检查。

当用户的主要意图是以下情况时，改用其他技能：

• 深度安全审计、SAST、授权、密钥、租户隔离、可利用性或 CVSS 报告 -> forge-security-review。
• 成本优化、调用次数、GB-秒、存储/日志量、触发器频率或内存调优 -> forge-cost-optimizer。
• 已知故障、错误消息、空白 UI、部署/安装失败、解析器损坏、应用缺失或日志/隧道诊断 -> forge-debugger。

如果广泛审查发现深层安全/成本/调试问题，请将其作为交接建议包含在内，而不是重复专业工作流。

审查规则

• 先审计。除非用户明确要求应用修复，否则不要修改应用文件。
• 在做出判断前先阅读代码库。
• 优先提供具体的文件/行证据。
• 将发现集中在 bug、发布阻碍、重大风险和缺失的验证上。
• 不要从此技能运行完整 SAST 或成本工具。在有正当理由时推荐专业技能。
• 不要将推测性的安全或成本观察报告为已确认的漏洞或节省。

模块与能力路由

检测 manifest.yml 或包依赖中声明的模块，并加载特定的审查指南：

• Teamwork Graph / Forge Connectors：
  • 如果应用声明了 graph:connector、teamwork-graph-connector，或导入了 @forge/teamwork-graph：
  • 👉 遵循并依据 ./modules/connector-review.md 进行评估。

---

工作流

1. 阅读 manifest.yml 或 manifest.yaml。
   • 识别模块、资源、函数、解析器绑定、触发器、Web 触发器、远程、权限、运行时和内存设置。
   • 验证引用的处理程序/资源存在。
2. 阅读 package.json。
   • 检查 Forge 包适配性、脚本、运行时假设、直接依赖，以及明显未使用/缺失的包。
3. 检查源文件。
   • 后端/解析器：resolver.define、处理程序导出、产品 API 调用、存储使用、外部抓取、日志记录、错误处理。
   • 前端：UI Kit 或 Custom UI 资源入口点、invoke() 模式、桥接使用、加载/错误状态。
4. 在存在时检查测试和项目文档。
   • 仅当行为风险证明合理时，才注明缺失的测试。
5. 生成按优先级排序的就绪报告。

检查内容

发布阻碍

• Manifest 引用了缺失的处理程序、资源路径或模块键。
• 前端调用的解析器名称与 resolver.define() 名称不匹配。
• 实际 API/抓取使用缺少所需的作用域或出口权限。
• 运行时、包版本或模块语法可能导致 forge lint、构建、部署或安装失败。
• 应用没有明确的方式演练其主要用户流程。

架构与可维护性

• 模块类型与预期的 UX 界面匹配。
• 解析器边界连贯，且对于应用规模而言不过于单一化。
• 敏感或特权逻辑保留在后端。
• 仅 UI 的格式化/转换不必强制通过后端函数。
• 对于面向用户的工作流，错误处理充分。
• 代码组织与现有项目风格匹配。

轻量级安全信号

仅标记明显的信号，并建议使用 forge-security-review 进行深度验证：

• 广泛/写入/管理权限范围，但看不到实际用途。
• 在用户触发的 resolver 中使用 api.asApp()，却没有明显的授权检查。
• 硬编码的凭据或类似令牌的字面量。
• 外部 fetch 却没有清单中的出口（egress）条目。
• Web 触发器没有可见的认证策略。
• 完整负载/请求日志记录，可能暴露用户、租户或机密数据。

轻量级成本信号

仅标记明显的信号，并建议使用 forge-cost-optimizer 进行深度分析：

• 仅仅为了返回静态数据或产品上下文而调用的 resolver。
• 页面加载时多次独立的 invoke() 调用。
• 看起来像大范围轮询的定时触发器。
• 产品触发器没有过滤器，或在适用时没有 ignoreSelf。
• 在热路径中记录完整负载/API 响应日志。
• 每次调用都进行存储写入。

轻量级可调试性信号

仅标记就绪性缺口；当存在已观察到的故障时，使用 forge-debugger：

• 异步 UI 路径周围缺少加载/错误状态。
• 重要故障周围的日志要么过于嘈杂，要么缺失。
• README 或脚本没有说明如何 lint/build/deploy/test。
• 除了 forge lint 之外，应用没有明显的本地验证命令。

输出格式

返回一份简洁的 Markdown 报告。Findings 必须是一个表格（不是编号列表）。为每条 finding 包含一个 Source 列，以便读者知道它来自哪个审查指南或领域。

Source 值（使用最具体且适用的值 — Source 是检查清单/模块或审查领域，而不仅仅是文件类型）：

• manifest — 一般的 Forge 清单接线、权限范围、出口（egress）或模块键，不由特定模块指南覆盖
• resolver — 后端/resolver 接线和运行时行为
• frontend — UI Kit / Custom UI invoke 和桥接模式
• dependencies — package.json / 运行时包适配
• tests — 缺失或不充分的验证
• general — 未在上面覆盖的跨领域就绪性卫生
• 特定模块标签 — 当加载模块审查指南时（位于 ./modules/ 下），使用该指南定义的 Source 标签（例如 connector）。不要仅仅因为证据位于 manifest.yml 中就把这些 findings 重新标记为 manifest。

Location 规则（不要只写路径）：

• 始终引用精确的 path:line 或 path:start-end（允许多个引用）。
• 在 Location 单元格中包含产生信号的贡献代码摘录 — 也就是产生该信号的确切行，而不只是文件名。
• 由于 Markdown 表格单元格无法可靠地嵌套 ``` 围栏，请将摘录用 HTML 包裹：<pre><code>...</code></pre>。
• 保持摘录紧凑（通常 ≤15 行）。对于缺失情况（例如缺少必需块），显示最近的包围片段，并在 Description 中说明缺少了什么。

# Forge App Review Results

## Summary
- Readiness: Ready | Needs changes | Blocked
- Highest-risk area: <manifest | resolver wiring | permissions | dependencies | tests | operational hygiene | module-specific>
- Files inspected: <short list>
- Specialist handoffs: <none | security | cost | debugger>

## Findings

| Severity | Source | Finding | Location | Description | Doc | Fix |
|----------|--------|---------|----------|-------------|---------|-----|
| Critical \| Warning \| Info | <source> | <short title> | `path:start-end`<br><pre><code>…excerpt…</code></pre> | <why this matters / observed pattern> | <DAC or checklist anchor title + URL> | <specific remediation> |

Sort rows Critical → Warning → Info. Omit the Doc column cell only when no public/doc anchor applies; keep the column.

## Clean Areas
- <important categories checked with no issues>

## Suggested Next Step
- <apply fixes | run specialist review | deploy/lint/test command>

如果没有 findings，请说明从这次一般审查来看该应用看起来已就绪，并列出任何有意排除在范围之外的残留专项审查。