Project Audit

全项目级别的结构和内容审计。不同于 stage-review（单阶段文档质量），project-audit 检查跨文件、跨目录的全量一致性。

定位

When to Use

• 快速孵化完成后（express-incubate 末尾）
• 阶段切换前（需求→架构、架构→交付）
• 生成 implementation-kit 之前
• 用户说"检查项目"、"审计"、"verify"、"review project"
• 用户说"分析孵化情况"、"看看还有什么缺的"

Input

Output

Output Schema

{
  "project": "<项目名>",
  "timestamp": "ISO 8601",
  "depth": "quick|standard|deep",
  "score": 75,
  "verdict": "PASS|WARNING|NEEDS_FIX|BLOCKED",
  "categories": {
    "structure": {"status": "PASS|WARNING|BLOCKER", "score": 0-100, "issues": [...]},
    "files": {"status": "...", "score": 0-100, "issues": [...]},
    "navigation": {"status": "...", "score": 0-100, "issues": [...]},
    "coherence": {"status": "...", "score": 0-100, "issues": [...]},
    "traceability": {"status": "...", "score": 0-100, "issues": [...]},
    "compliance": {"status": "...", "score": 0-100, "issues": [...]},
    "phase": {"status": "...", "score": 0-100, "issues": [...]}
  },
  "findings": {
    "blockers": [{"id": "F1", "desc": "...", "fix": "..."}],
    "warnings": [{"id": "C5", "desc": "...", "fix": "..."}],
    "infos": [{"id": "N2", "desc": "...", "suggestion": "..."}]
  }
}

Minimum Viable Output

最少包含：

• 7 个维度的 pass/warning/blocker 判定
• 每个异常的检查项 ID、描述、修复建议
• 总分和 verdict

Complete Output

完整输出包含：

• Minimum Viable Output 全部内容
• 每个异常的具体文件路径和行号
• 深度模式下逐文件内容质量评定
• 修复优先级排序
• reports/audit/<timestamp>.json + reports/audit/<timestamp>.md

文件产出

Dependencies

Procedure

Phase 1: 确定审计深度

Phase 2: 7 维度逐项检查

① 结构完整性（Structure）

检查实际目录结构 vs 模板结构。

express-incubate 特例：以下目录在快速模式下允许为空的（但应有 README 说明）：

• wiki/02-research/、wiki/04-data-and-api/、wiki/06-quality/、wiki/07-operations/
• reports/ 子目录

② 文件完整性（Files）

检查各目录下的文件是否齐全。

最小文件集（即使快速模式也应存在）：

• HOME.md, wiki/00-overview/vision.md, wiki/00-overview/scope.md
• wiki/01-requirements/user-stories.md, wiki/01-requirements/constraints.md
• wiki/01-requirements/assumptions.md, wiki/01-requirements/open-questions.md
• wiki/03-architecture/system-design.md
• wiki/05-delivery/task-breakdown.md, tasks/backlog.md

F6 阶段-交付物映射：

③ 导航一致性（Navigation）

N2 增强：如果项目已生成 implementation-kit，HOME.md 导航至少应覆盖：

• wiki/02-research/risk-register.md（风险登记）
• wiki/06-quality/acceptance-plan.md（验收计划）
• wiki/07-operations/deployment.md（部署说明）

④ 内容一致性（Coherence）

C7 增强规则：

• 如果 implementation-kit/ 已存在且有内容，但 HOME.md 阶段写"架构设计中"→ WARNING（应至少为"设计验收"）
• 如果 wiki/05-delivery/task-breakdown.md 有完整任务拆解，但 HOME.md 阶段写"需求澄清中"→ WARNING

⑤ 可追踪性（Traceability）

T5 执行记录检查：

• 检查 reports/execution/express-incubate-*/summary.md 是否存在
• 如果 implementation-kit 存在但 execution-log 缺失 → 🟡 WARNING（说明孵化被中断或 skill 版本不支持）
• 如果项目使用旧流程（无 express-incubate），检查是否有 reports/execution/ 目录及 README 说明
• execution-log 是 express-incubate 项目的必需产出，缺失表明孵化流程不完整

⑥ 规范合规（Compliance）

L5 核心页面清单（deep 模式下检查）：

• wiki/00-overview/vision.md
• wiki/00-overview/scope.md
• wiki/03-architecture/system-design.md
• wiki/04-data-and-api/api-spec.md
• wiki/07-operations/deployment.md

L6 最低内容判定：

• 环境划分：至少有 local 和 production/docker 两种环境的说明
• 依赖服务：列出运行时依赖（含版本要求）
• 部署步骤：可执行的命令序列
• 回滚入口：明确的回滚方式

⑦ 阶段合规（Phase）

P3 实质内容判定：

• 页面非空
• 至少有一节具体内容（不只是"待补充"或"TODO"）
• 无大面积空白表格

Phase 3: 输出报告

1. 汇总每个维度的 PASS/WARNING/BLOCKER/INFO
2. 计算总分（每个 WARNING -5，BLOCKER -15）
3. 对每个异常给出：检查项 ID、描述、具体文件路径/行号、修复建议
4. 按严重性排序：BLOCKER → WARNING → INFO
5. 生成 reports/audit/<timestamp>.json 和 .md
6. 呈现给用户；如存在需要业务决策的 BLOCKER，再使用当前环境可用的用户输入方式确认

评分计算

总分 = 100
- BLOCKER × 15
- WARNING × 5
- INFO × 0
最低 0 分

检查项密度矩阵

Target Pages

• <项目根目录>/reports/audit/<timestamp>.json
• <项目根目录>/reports/audit/<timestamp>.md

Enriched Behavior

执行前环境检查

执行审计前，必读以下文件以获取基准：

1. 仓库根目录 ../../../PROJECT_WIKI_TEMPLATE.md — 获取唯一标准结构定义
2. <项目>/HOME.md — 获取项目当前阶段声明
3. 根据深度决定是否读取所有 wiki 文件

自检机制

完成审计后，对照本 skill 的检查项清单自查：是否每一项都实际执行了（而非仅凭印象判断）。

Changelog