ln-629-runtime-lifecycle-config-auditor

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

运行时生命周期与配置审计器（L3 Worker）

**类型：**L3 Worker

专门负责审计运行时就绪状态、生命周期和启动配置验证的 Worker。

目的与范围

• 审计运行时生命周期和配置验证（类别 12：中优先级）
• 检查引导、关闭、信号处理、探针、资源清理、环境变量/配置同步，以及启动时快速失败验证
• 生成 FIX_BOOTSTRAP、ADD_CONFIG_VALIDATION 或 FIX_SHUTDOWN
• 计算合规评分（X/10）

输入

**必须读取：**加载 references/audit_worker_core_contract.md 和 references/mcp_tool_preferences.md。 工具策略：你可能会作为独立子 Agent 运行，此时宿主的 AGENTS.md 不在适用范围内，因此读取、搜索和编辑文件时默认优先使用 hex-line MCP。仅当 MCP 行为不明确时，才加载 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 连接
• 验证文件句柄是否已释放
• 检查 Worker 线程是否已停止

严重性：

• **中：**关闭时存在资源泄漏

**建议：**在关闭处理程序中关闭所有资源

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

4. 信号处理

检测：

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

严重性：

• **中：**缺少信号处理程序

**建议：**处理所有标准信号

**工作量：**S（添加信号处理程序）

5. 存活/就绪探针

检测（针对容器化应用）：

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

严重性：

• **MEDIUM：**没有探针（Kubernetes 无法检测健康状况）

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

**工作量：**S（添加端点）

6. 启动配置验证

检测：

• 查找启动路径中的环境变量/配置读取
• 检查是否使用验证框架或显式的快速失败检查
• 在可用时，将代码中的必需运行时变量与文档中的启动配置进行比较

严重性：

• **HIGH：**必需配置缺失时，应用仍可能启动
• **MEDIUM：**默认值/不同步可能导致本地、CI 和已部署环境的启动行为不同

**建议：**在启动时验证必需配置，并在接受流量前失败退出

**工作量：**M

评分算法

**必须阅读：**加载 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: "Runtime Lifecycle & Config"，检查项为：bootstrap_order、graceful_shutdown、resource_cleanup、signal_handling、probes、startup_config_validation。

按照 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
• **独特范围：**仅审计运行时就绪状态和启动配置验证。不要审计配置架构边界、软件包健康状况或诊断遥测。
• **必须采取行动：**每项发现都使用 FIX_BOOTSTRAP、ADD_CONFIG_VALIDATION 或 FIX_SHUTDOWN

完成定义

应用已加载的 references/audit_worker_core_contract.md。

• 已解析 contextStore（部署类型、output_dir）
• 已完成全部 6 项检查（引导顺序、优雅关闭、资源清理、信号处理、探针、启动配置验证）
• 已收集问题发现及其严重性、位置、工作量、操作和建议
• 已按照 references/audit_scoring.md 计算评分
• 已将报告写入 {output_dir}/ln-629--global.md（通过一次原子 Write 调用）
• 已按照契约写入摘要

---

**版本：**3.0.0 **上次更新：**2025-12-23