ln-629-runtime-lifecycle-config-auditor

パス： ファイルパス（references/、../ln-*）は、このスキルディレクトリからの相対パスです。

ランタイムライフサイクルと設定の監査担当（L3 ワーカー）

タイプ： L3 ワーカー

ランタイムの準備状況、ライフサイクル、起動設定の検証を監査する専門ワーカーです。

目的と範囲

• ランタイムのライフサイクルと設定の検証を監査します（カテゴリ 12：中優先度）
• ブートストラップ、シャットダウン、シグナル処理、プローブ、リソースのクリーンアップ、環境変数と設定の同期、起動時のフェイルファスト検証を確認します
• FIX_BOOTSTRAP、ADD_CONFIG_VALIDATION、または FIX_SHUTDOWN を出力します
• 適合スコア（X/10）を算出します

入力

必須の読み込み： references/audit_worker_core_contract.md と references/mcp_tool_preferences.md を読み込みます。 ツールポリシー：ホストの AGENTS.md が対象範囲外の独立したサブエージェントとして実行される場合があるため、ファイルの読み取り、検索、編集には、まず hex-line MCP を使用してください。MCP の動作が不明確な場合に限り、references/mcp_integration_patterns.md を読み込みます。

tech stack、deployment type、codebase root、output_dir を含む contextStore を受け取ります。

ライフサイクルの追跡によって確信度が大きく向上する場合は、まず hex-graph を使用してください。ローカルコードの読み取りには、利用可能な場合、まず hex-line を使用してください。MCP が利用できない、未対応、またはインデックス化されていない場合は、組み込みの Read/Grep/Glob/Bash で続行し、レポートにフォールバックしたことを記載してください。

ワークフロー

検出ポリシー：2 層検出（候補のスキャン、その後にコンテキストの検証）を使用します。検証方法が曖昧な場合に限り、references/two_layer_detection.md を読み込みます。

1. コンテキストと output_dir を解析します
2. ライフサイクルと設定検証のパターンを確認します（レイヤー 1：SIGTERM、シャットダウンハンドラー、プローブ、環境変数の読み取り、設定検証を grep します）
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. ブートストラップの初期化順序

検出：

• メイン／インデックスファイルで初期化シーケンスを確認します
• 使用前に依存関係が読み込まれていることを確認します（ルートより先に DB）

重大度：

• 高： 順序の誤りによって起動に失敗します

推奨事項： 正しい順序で初期化します：config -> DB -> routes -> server

工数： M（起動処理のリファクタリング）

2. グレースフルシャットダウン

検出：

• SIGTERM、SIGINT のハンドラーを grep します
• process.on('SIGTERM')（Node.js）を確認します
• signal.Notify（Go）を確認します

重大度：

• 高： シャットダウンハンドラーがなく、突然終了します

推奨事項： SIGTERM ハンドラーを追加し、接続をグレースフルに閉じます

工数： M（シャットダウン処理の追加）

3. 終了時のリソースクリーンアップ

検出：

• シャットダウン時に DB 接続が閉じられるか確認します
• ファイルハンドルが解放されているか確認します
• ワーカースレッドが停止しているか確認します

重大度：

• 中： シャットダウン時にリソースリークが発生します

推奨事項： シャットダウンハンドラーですべてのリソースを閉じます

工数： 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 = 1 時間未満、M = 1～4 時間、L = 4 時間超
• 対象外： CLI ツールとスクリプト（長時間実行されるライフサイクルがないため）、サーバーレス関数（ライフサイクルがプラットフォームによって管理されるため）は対象外です
• 初期化順序は重要： コンテキストにかかわらず、DB 初期化前の DB 使用には 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