ln-629-lifecycle-auditor

路径： 文件路径（references/、../ln-*）均相对于此技能目录。

生命周期审计器（L3 Worker）

类型： L3 Worker

专门审计应用程序生命周期和入口点的 Worker。

目的与范围

• 审计生命周期（类别 12：中优先级）
• 检查引导、关闭、信号处理和探针
• 计算合规评分（X/10）

输入

必须阅读： 加载 references/audit_worker_core_contract.md。 工具策略：遵循宿主 AGENTS.md 中的 MCP 偏好设置；仅当宿主策略缺失或 MCP 行为不明确时，才加载 references/mcp_tool_preferences.md 和 references/mcp_integration_patterns.md。

接收包含技术栈、部署类型、代码库根目录和 output_dir 的 contextStore。

如果生命周期追踪能显著提高判断把握度，请先使用 hex-graph。如果可用，请先使用 hex-line 读取局部代码。如果 MCP 不可用、不受支持或未建立索引，请继续使用内置的 Read/Grep/Glob/Bash，并在报告中说明回退方案。

工作流

检测策略：采用两层检测（候选项扫描，然后上下文验证）；仅当验证方法不明确时，才加载 references/two_layer_detection.md。

1. 解析 context + output_dir
2. 检查生命周期模式（第 1 层：搜索 SIGTERM、关闭处理器、探针）
3. 针对每个候选项分析上下文（第 2 层）：
   • 引导顺序：读取主文件——追踪实际初始化顺序，验证依赖项是否在使用前就绪
   • 优雅关闭：读取信号处理器——它们是否确实关闭所有资源？还是只记录日志并退出？
   • 资源清理：读取关闭处理器——是否关闭了所有已打开的资源（DB、Redis、队列）？
   • 探针：检查部署配置（Dockerfile、k8s 清单）——应用是否容器化？
4. 收集已确认的发现
5. 计算评分
6. 编写报告： 根据 references/templates/audit_worker_report_template.md 在内存中构建完整的 Markdown 报告，并通过一次 Write 调用写入 {output_dir}/ln-629--global.md
7. 返回摘要： 向协调器返回最简摘要

审计规则

1. 引导初始化顺序

检测：

• 检查 main/index 文件中的初始化顺序
• 验证依赖项是否在使用前加载（路由前加载 DB）

严重性：

• 高： 顺序错误会导致启动失败

建议： 按正确顺序初始化：config -> DB -> routes -> server

工作量： M（重构启动流程）

2. 优雅关闭

检测：

• 搜索 SIGTERM、SIGINT 处理器
• 检查 process.on('SIGTERM')（Node.js）
• 检查 signal.Notify（Go）

严重性：

• 高： 没有关闭处理器（进程突然终止）

建议： 添加 SIGTERM 处理器，优雅地关闭连接

工作量： M（添加关闭逻辑）

3. 退出时清理资源

检测：

• 检查 DB 连接是否在关闭时关闭
• 验证文件句柄是否已释放
• 检查工作线程是否已停止

严重性：

• 中： 关闭时发生资源泄漏

建议： 在关闭处理器中关闭所有资源

工作量： S-M（添加清理调用）

4. 信号处理

检测：

• 检查 SIGTERM、SIGINT、SIGHUP 的处理器
• 验证信号是否正确传递给子进程

严重性：

• 中： 缺少信号处理器

建议： 处理所有标准信号

工作量： S（添加信号处理器）

5. 存活/就绪探针

检测（适用于容器化应用）：

• 检查是否存在 /live、/ready 端点
• 验证 Kubernetes 探针配置

严重性：

• 中： 没有探针（Kubernetes 无法检测健康状态）

建议： 添加 /live（是否正在运行）和 /ready（是否已准备好接收流量）

工作量： S（添加端点）

评分算法

必须阅读： 加载 references/audit_scoring.md。

输出格式

必须阅读： 加载 references/templates/audit_worker_report_template.md。

根据 references/audit_summary_contract.md 编写 JSON 摘要。在托管模式下，调用方会传入 runId 和 summaryArtifactPath；在独立模式下，工作器会根据共享契约生成自己的运行范围工件路径。

将报告写入 {output_dir}/ln-629--global.md，并设置 category: "Lifecycle"，检查项包括：bootstrap_order、graceful_shutdown、resource_cleanup、signal_handling、probes。

根据 references/audit_summary_contract.md 返回摘要。

如果未提供 summaryArtifactPath，则将独立运行时摘要写入 .hex-skills/runtime-artifacts/runs/{run_id}/evaluation-worker/{worker}--{identifier}.json，并可选择在结构化输出中回显相同的摘要。

Report written: .hex-skills/runtime-artifacts/runs/{run_id}/audit-report/ln-629--global.md
Score: X.X/10 | Issues: N (C:N H:N M:N L:N)

参考文件

• 审计输出架构： references/audit_output_schema.md

关键规则

遵循已加载的 references/audit_worker_core_contract.md。

• 不要自动修复： 仅报告问题，生命周期变更可能导致停机
• 考虑部署类型： 根据部署类型调整探针检查（Kubernetes = 必须配置探针，裸机 = 可选）
• 工作量评估务必切合实际： S = <1h，M = 1-4h，L = >4h
• 排除项： 跳过 CLI 工具和脚本（没有长期运行的生命周期），跳过无服务器函数（生命周期由平台管理）
• 初始化顺序很重要： 无论上下文如何，都将数据库初始化前使用数据库标记为 HIGH

完成定义

遵循已加载的 references/audit_worker_core_contract.md。

• 已解析 contextStore（部署类型、output_dir）
• 已完成全部 5 项检查（引导顺序、优雅关闭、资源清理、信号处理、探针）
• 已收集包含严重程度、位置、工作量和建议的问题
• 已根据 references/audit_scoring.md 计算评分
• 已将报告写入 {output_dir}/ln-629--global.md（通过一次原子 Write 调用）
• 已根据契约写入摘要

---

版本： 3.0.0 最后更新： 2025-12-23