对 Cathedral 代码库执行完整的规格‑代码审查。适用于构建阶段、重大重构后或怀疑规格与代码漂移时。生成正向审查。
大教堂审计: 用于测量和关闭大教堂C#代码库中光谱码漂移的结构化过程
功能概述
大教堂审计: 用于测量和关闭大教堂C#代码库中光谱码漂移的结构化过程是一项面向实际任务的技能，主要用于在建设波( 多个特性/ 因素着陆) 之后。它将相关步骤、工具调用和结果整理方式集中到统一流程中，帮助使用者更快完成目标并减少重复操作。
核心要点
- 使用时应结合输入条件选择合适的执行方式，核对必要参数、依赖环境与输出内容，并按原始要求处理异常情况。
- 该技能适合需要稳定复用相关能力的场景，可作为自动化工作流的一部分，也便于后续检查、调整和扩展。
- 从功能定位来看，该技能强调把分散的操作要求整理成清晰、可复用的处理流程，使用户能够围绕既定目标快速准备输入、选择执行方式并获得结构化结果。
使用与执行
实际使用前应先确认任务范围、数据来源、运行环境、必要权限和关键参数，再依据技能说明逐步执行；若输入条件不完整，应先补齐信息或采用保守配置，避免因错误假设导致结果偏离需求。
结果检查与注意事项
执行过程中需要关注工具调用是否成功、接口或依赖是否可用、输出格式是否符合预期，并对异常提示、缺失字段和边界情况进行处理；涉及批量任务时，还应保存进度，避免中断后重复操作。
大教堂审计（Cathedral Audit）
一套结构化流程，用于度量并消除 Cathedral C# 代码库中规范（spec）与代码之间的偏差（spec-code drift）。
执行时机
- 一次构建波次（build wave）完成后（多个功能/重构已合入）
- 启动新重大功能开发前（建立基线）
- 怀疑存在 spec-code drift 时
- 作为健康检查定期执行（不按日历周期，而依据事件触发）
流程概览
1. 正向审计（规范 → 代码） 2. 反向审计（代码 → 规范） 3. 整合与优先级排序 4. 执行 5. 验证
步骤 1：正向审计（规范 → 代码）
针对 kitty-specs/ 目录下的每一份规范，比对规范所述内容与实际代码行为是否一致。
每份规范的输出结果为以下之一：
- ✅ 符合（Conformant） — 代码行为与规范完全一致
- ⚠️ 偏离（Divergent） — 代码存在，但行为与规范不一致
- ❌ 缺失（Missing） — 规范描述了尚未实现的功能
交付物：kitty-specs/000-project-context/spec-audit-YYYY-MM-DD.md
若内存充足，可使用并行 CC agent（每个 agent 处理一批规范）以加速。**在内存受限主机（如 WSL2）上，请务必串行运行 —— 同时运行两个 CC 会话将导致 OOM。** 请为每个 agent 授予只读访问权限。
步骤 2：反向审计（代码 → 规范）
扫描 src/Cathedral.Core/ 和 src/Cathedral.TestHarness/ 下所有 .cs 文件。对每个文件或子系统，判断：
- 是否被某份规范覆盖？
- 其行为是否与对应规范一致？
- 是否为无用/孤立（dead/orphaned）代码？
输出应包含以下章节：
- 执行摘要（Executive Summary） — 各类问题数量统计，并对比上一次审计的增量变化
- 未覆盖代码（Unspecced Code） — 未被任何规范覆盖的文件/子系统
- 架构偏离（Architectural Divergences） — 代码实现路径与规范存在根本性差异
- 超出规范的代码（Code Exceeding Spec） — 代码实现了规范中未记载的功能
- 无用/孤立代码（Dead/Orphaned Code） — 无调用者、无引用的文件
- 发现的缺陷（Bugs Discovered） — 审查过程中发现的运行时、数据或逻辑缺陷
- 与上一次审计的对比（Comparison with Previous Audit） — 哪些问题已改善，哪些仍待解决
交付物：kitty-specs/000-project-context/reverse-audit-YYYY-MM-DD.md
若内存充足，可使用并行 CC agent（按目录/子系统分组文件）以加速。**在内存受限主机上请串行运行。**
步骤 3：整合与优先级排序
将正向与反向审计的所有发现合并，形成一份带优先级的行动方案：
| 优先级 | 类别 | 判定标准 |
|---|---|---|
| P0 | 缺陷修复 | 具有运行时影响 — 如接口中断、数据损坏、崩溃 |
| P1 | 移除无用代码 | 安全删除，可降低理解成本与代码行数（LOC） |
| P2 | 数据质量修复 | 数据丢失、默认值错误、重复日志等 |
| P3 | 补充规范覆盖 | 为未被规范覆盖的代码编写新规范（不修改代码） |
| P4 | 提升规范准确性 | 更新现有规范，以记录“超出规范的代码”所实现的功能 |
| P5 | 机械式重构 | 重命名、依赖注入配线（wiring）、实体作用域补全等 |
| P6 | 架构缺口 | V2 功能中，代码因设计原因主动偏离规范（暂缓处理） |
规则：
- 缺陷必须单独成节，并标注严重程度
- “超出规范的代码”对应操作是更新规范，而非修改代码
- 因设计原因主动推迟（V2 工作）的架构偏离归入 P6，需记录但暂不执行
- 每个优先级层级的工作应可在单次 CC session 内完成
交付物：反向审计报告中的“建议（Recommendations）”章节。
步骤 4：执行
按优先级层级顺序执行修复（P0 最先，P6 最后或暂缓）。
每个优先级层级需执行以下操作：
- 记录意图至
memory/YYYY-MM-DD.md— 包含层级名称、CC session 名称、拟执行内容 - 为 CC 编写任务简报（参见
references/cc-task-template.md） - 启动 CC session：
cat /tmp/task.md | claude -p --allowedTools 'Edit,Write,Read,Bash' - 配置监控定时任务（每 5 分钟执行一次）
- CC 完成后：记录结果至当日 memory 文件 — 包括变更文件列表、具体操作、遇到的问题
- 提交前必须验证构建成功 —
dotnet build必须通过 - 若 CC 因 OOM 被终止：检查
git diff --stat，手动验证构建，修复问题，并记录该事件 - 提交时使用具备描述性的提交信息，并引用对应优先级层级
- 将提交哈希（commit hash）记录至当日 memory 文件
硬性规则：
- ⚠️ 提交前必须始终验证
dotnet build通过。 无例外。CC 可能在构建检查中途被 OOM 终止。 - ⚠️ 每一步操作都必须记录至当日 memory 文件。 启动前记录意图，完成后记录结果，提交后记录 commit hash。即使 session 中断，日志仍可留存用于恢复。
- 每个优先级层级（或逻辑上紧密关联的一组任务）仅生成一次提交
每日 memory 日志模板：
## [优先级层级名称] - CC session：[名称]（约 HH:MM CST 启动） - 任务：[简要描述] - 状态：[RUNNING | ✅ COMPLETE | ❌ FAILED | ⚠️ KILLED] - 变更文件数：[数量] - 关键操作：[具体执行内容] - 问题：[遇到的任何问题] - 已提交为 [hash]
步骤 5：验证
全部优先级层级执行完毕后，可选择快速复审以评估改进效果：
- 对比各项计数：未覆盖代码、偏离项、无用代码、缺陷数
- 验证各指标变化是否符合预期
- 记录剩余缺口，并说明其属于 P6/暂缓项，还是新发现的问题
交付物：更新后的审计文件，含对比分析章节。
日志记录
每次审计均须在 memory/YYYY-MM-DD.md 中留下完整追踪记录：
- 审计启动 — 当前执行的审计类型、参考基线
- 审计结果 — 汇总计数、关键发现
- 各优先级层级 — 意图、CC session、结果、问题、commit hash
- 最终摘要 — 总提交数、总代码行变更数、已解决项 vs 暂缓项
此项为强制要求。2 月 17–18 日的“失忆事件”已证实：未记录的工作即为丢失的工作。“先记录，再执行” —— 在开展任何操作前，先写下你将要做的事；操作完成后，立即更新结果。
基线追踪
所有审计均须与上一次审计结果对比。审计文件按如下方式存储：
kitty-specs/000-project-context/ spec-audit-YYYY-MM-DD.md （正向审计） reverse-audit-YYYY-MM-DD.md （反向审计）
带差值的执行摘要表是核心度量指标：
| 类别 | 上次 | 当前 | 差值 | |----------|----------|---------|-------| | 未覆盖代码 | 38 | 24 | -14 | | 偏离项 | 12 | 7 | -5 | | 无用代码 | 14 | 8 | -6 | | 缺陷 | 0 | 8 | +8 | | 符合项 | ~60 | ~120 | +60 |
CC 任务简报模板
标准 CC 任务简报格式详见 references/cc-task-template.md。
相关专题
本专题介绍Gradle插件开发的基本流程，涵盖插件类编写、自定义任务注册、扩展参数设计和插件应用方法，帮助你理解插件如何组织构建逻辑，减少多个项目之间的重复配置。
2026.10.22
0
11
本专题介绍Gradle Wrapper的基本作用，涵盖文件组成、生成方法、版本配置和任务调用，帮助你理解项目如何使用指定的Gradle版本，减少不同开发环境带来的构建差异。
2026.10.22
0
10
本专题整理Golangci-lint常用Linters的用途与配置方法，覆盖错误处理、无效代码、安全、复杂度、命名和依赖检查，帮助项目合理选规则。
2026.10.22
0
15
本专题介绍Gradle Java项目构建方法，涵盖Java插件配置、依赖声明、源码编译、测试执行和打包检查，帮助你理解各阶段的任务关系，逐步完成项目构建。
2026.10.22
0
10
本专题汇总PHP常见时间戳漏洞，包括2038年溢出、时区漂移、时间戳伪造、重放攻击、时间盲注与日志审计失效等，并给出升级64位环境、使用 DateTimeImmutable、统一UTC、严格超时校验、预处理绑定、hash_equals 比对等修复方案，帮助开发者快速排查和加固时间相关代码。
2026.10.22
0
25
本专题聚焦Golangci-lint YAML配置文件，讲清运行参数、规则启停、目录排除、问题过滤及严重级别设置，便于团队统一检查标准。
2026.10.22
0
15
本专题讲解Golangci-lint的安装、初始化、基础命令和首次代码检查，覆盖本地环境、Docker及多平台用法，帮助Go开发者快速上手。
2026.10.22
0
15
PHP2Shell漏洞是什么，哪些PHP版本和运行环境会受到影响，服务器应该如何检测与修复？本专题提供版本自查脚本、Linux与Docker升级命令、PHP-FPM和Apache排查步骤，以及修复验证、临时缓解和应急响应方案。
2026.10.22
0
12
热门下载
相关下载
精品课程
共6课时 | 54.7万人学习
共89课时 | 134万人学习
共49课时 | 82.5万人学习
