MAS-124: 31タブ発注残高エイジング＆超過発注アラート

概要

目的

31_wrk_order の発注残高の滞留・異常値を自動検知する監視機構を整備し、発注統制を強化する。具体的には次の 3 つの機能を提供する。

1. 超過発注検知: 発注残高(自動計算) < 0（INV 過剰紐付け）を 🔴 ハイライト。
2. 長期未消化エイジング: 終了年月 を過ぎても 発注残高(自動計算) > 0 の ORD を滞留日数別（30日 / 60日 / 90日 / 90日超）に分類し、🟠 ハイライト。
3. 発注ステータス自動更新候補の抽出: 発注残高(自動計算) = 0 かつ紐づく INV が全て承認済の ORD を「完納」相当のステータスへ遷移する候補として収集し、人間の確認のうえ OrderRepository.save() で一括更新する（Human-in-the-Loop）。

現在のコード

エイジング管理・超過検知・ステータス自動遷移の専用ロジックは未実装。現状は以下の部分的チェックのみ存在する。

• 200_data/201_data_validator.js L447-462 validateOrder_: 発注残高(自動計算) がマイナスのセルに VAL_COLORS.WARNING（#FCE5CD）を付与し、メモ [VAL] 発注残高がマイナスです（INV過剰紐付けの可能性） を設定するのみ。
• docs/spec/spec_data_validation.md L155: O01 発注残高(自動計算) マイナスはNG (INV過剰紐付け) 警告 として仕様に明記済だが、色分けは警告色のみで 🔴 強調なし。
• 400_domain/410_subledger_engine.js L106 processInvoiceApprovals（Action A）が発注残高を ordSheet.getRange(ordMap[ordId].rowIndex, iOrdBalance + 1).setValue(newBal) で直接書き込む（= GAS 管理、Sheets 数式ではない）。
• OrderDTO の 発注ステータス 列挙値は "見積中" | "発注済" | "検収済" のみ（000_infra/003_contracts.js L32）。「完納」ステータスは JSDoc・MST_DICT ともに未登録（Phase 1 実データ検証参照）。

再利用する既存関数・データ:

修正方針

新規ファイルの配置

• 400_domain/411_order_aging.js（新規作成） にメインロジックを置く。理由: (a) 発注残高エイジング判定・ステータス自動遷移は業務ロジック（会計ロジックの理解が必要）であり、400_domain/ が適切。(b) 201_data_validator.js は「受動的なデータ不整合の検出」専用で、本案件のようなステータス遷移（副作用あり）は置かない。(c) 400_domain/ の既存番号の空き番（410_subledger_engine.js の次、420_project_profitability.js の前）として 411 を採用。
• 200_data/201_data_validator.js には validateOrder_ に超過発注（発注残高 < 0）の色分けを 🔴 Constants.COLORS.WARN_RED_BG に格上げするマイナー改修のみ行う（エイジング本体は置かない）。既存のメモ文言は維持。

新設公開 API

400_domain/411_order_aging.js:

var OrderAgingService = {
  /** メニュー公開: エイジング計算 + 超過発注ハイライト + ステータス自動更新候補の確認・適用 */
  runOrderAging: function() { return runOrderAging(); }
};

function runOrderAging() { /* ...データフロー 1〜7 */ }

データフロー（番号付き手順）

1. LockService.getScriptLock() を取得し lock.waitLock(30000) で多重実行を防止（try { ... } finally { lock.releaseLock(); }）。
2. OrderRepository.findAll() で全発注 DTO とヘッダーを取得（{ headers, dtos }）。
3. InvoiceRepository.findAll() で全請求 DTO を取得し、親発注ID(ORD) をキーとする Map<string, InvoiceDTO[]> を構築する（有効フラグ=TRUE かつ 請求ステータス !== "却下" の INV のみ採用）。Map を使うことで発注ループ内 O(1) 検索になる。
4. 各発注 DTO を走査し、次の 3 判定を同時に行う（有効フラグ=FALSE および 発注ステータス = "検収済" はスキップ）:
   • ① 超過発注判定: Utils.parseAmt(dto['発注残高(自動計算)']) < 0 → 31_wrk_order の 発注残高(自動計算) 列を Constants.COLORS.WARN_RED_BG でハイライト。
   • ② エイジング判定: Utils.parseDateToYm(dto['終了年月']) が空文字なら対象外（継続契約・無期限）。空でない場合、当月 "YYYY-MM" と比較し、滞留月数（当月 − 終了月 の月差）を算出。残高 > 0 かつ滞留月数 > 0 の場合、区分に応じた背景色を 終了年月 セルに適用（エッジケーステーブルの「色分けルール」を参照）。
   • ③ ステータス自動更新候補抽出: Utils.parseAmt(dto['発注残高(自動計算)']) === 0 かつ紐づく有効 INV が 1 件以上あり、かつ全て 請求ステータス = "承認済" の ORD を候補リストに追加（{ ordId, beforeStatus, afterStatus }）。afterStatus は Phase 1-E「実データ検証」で業務確定した値（MCP 未確認なら空のまま候補リストを UI に表示して人間に判断させる）。
5. ハイライト書き込み: bg / notes 2 次元配列を構築して sheet.getRange(1,1,rowCount,colCount).setBackgrounds(bg) / setNotes(notes) で一括適用する（Repository パターン外の直接操作だが、セルの見た目の装飾のみでデータは書き換えないため例外的に許可）。既存の applyValidationResults_ パターン（201_data_validator.js L156-199）と同様に、Constants.COLORS.WARN_RED_BG と同型エイジング色のみをクリア対象にすることで他の書式との干渉を避ける。
6. ステータス自動更新候補がある場合、SpreadsheetApp.getUi().alert(..., ButtonSet.YES_NO) で候補一覧（ORD_ID と遷移先ステータス）を提示し、YES の場合のみ以下を実行:
   • 候補 DTO の 発注ステータス フィールドを書き換え、OrderRepository.save(dtos) で全行置換。
   • Utils.auditLog('UPDATE', '31_wrk_order', ordId, '発注ステータス', 'runOrderAging', before, after, 'S-52 エイジングによる自動遷移') を各候補について記録。
7. Utils.toastResult('runOrderAging', '🔎 超過X件・長期滞留Y件・ステータス自動更新Z件を処理しました', 8) で完了通知。Utils.logInfo でもログ出力。

フック挿入先

• Action A / Action B の末尾フック: Phase 1 調査の結果、runActionA_ / runActionB_ という関数は実在しない。実体は processInvoiceApprovals() (410_subledger_engine.js L106) と processSettlementClearings() (L365) であり、SubledgerService.processApprovals / processClearings として公開されている。本案件では Action A/B の末尾にフックを差し込む代わりに、独立したメニュー呼び出し（後述）として実装する。理由: (a) Action A/B は SpreadsheetApp.getUi().alert でエラー通知するフローのため、末尾でさらに alert を出すと UX が悪化する。(b) エイジング判定は日次で独立に行えば十分で、Action A/B の度に実行する必要はない。

• メニュー追加先: templates/operations_sidebar.html L71-76 の <div class="section"><h3>⚙️ メンテナンス</h3> ブロック内、既存の runDataValidation（L72）の直後に以下を 1 行追加する。

  <button class="btn" onclick="run('runOrderAging', this)">🗂️ 発注エイジング＆超過検知</button>
  

  造語を避け、既存セクション見出し「⚙️ メンテナンス」に合わせる（101_sys_config.js の onOpen() は単一メニュー「🚀 BizLP → 操作パネルを開く」のみで、実機能はサイドバー templates/operations_sidebar.html 側に集約されているため、101_sys_config.js の修正は不要）。

LockService

LockService.getScriptLock() を使用して Action A/B との競合を避ける。try { lock.waitLock(30000); ... } finally { lock.releaseLock(); } のパターンを厳守（既存の 410_subledger_engine.js は LockService 未使用だが、本案件は OrderRepository.save(dtos) による全行置換を行うため明示的に排他制御を入れる）。

影響範囲

既存ロジックへの影響:

• OrderRepository.save(dtos) は既存 writeDtosToSheet_ を通じて clearContent → setValues を行うが、発注残高(自動計算) は GAS 管理の数値のため、DTO の値をそのまま書き戻しても数式は消えない（Sheets 数式ではない）。セル背景色は setValues でクリアされないため、手順 5 のハイライト設定と順序は独立。
• validateOrder_ の色変更は runDataValidation の既存フローに影響するのみで、他バリデータへは影響しない。
• Action A/B とは明示的に排他ロックで分離されるため、実行中の書き込み競合は起こらない。

注意事項

1. 「完納」ステータス値は JSDoc・MST_DICT 未登録。Phase 1-E の実データ検証結果を踏まえて「afterStatus」を確定するまで、ステータス自動更新はバックエンド実装のみ行い、UI からは事前確認ダイアログで必ず人間が承認する（Human-in-the-Loop）。MCP 未確認で "完納" が実在しない場合は、候補リストを表示するのみで OrderRepository.save() は呼ばない（= ドライラン表示）。
2. 発注残高(自動計算) は GAS 管理（410_subledger_engine.js L332-339 が setValue で書き込む）であり、Sheets 数式ではない。OrderRepository.save(dtos) で上書きしても数式は消えない。ただし dto['発注残高(自動計算)'] 自体が有効な数値であることを事前に Utils.parseAmt で正規化すること（空文字が紛れると "" が書かれ、以降の再計算で NaN 化するリスク）。
3. セル背景色設定 (setBackgrounds) は Repository パターン外の直接操作だが、セル装飾のみでデータは変えないため本案件では例外的に許可する。実装では applyValidationResults_ 型のパターン（既存色を保持し、エイジング色・警告色のみをクリア → 新規適用）を採用し、他バリデータや条件付き書式との干渉を避ける。
4. LockService ロック: Action A/B と競合しないよう lock.waitLock(30000) を使う。タイムアウト時は SpreadsheetApp.getUi().alert でエラー表示し終了（無理に実行しない）。
5. 孤立 INV の扱い: 親発注ID(ORD) が ORD に存在しない（= 孤立 INV）の場合は、本案件のエイジング・超過判定では無視する（MAS-122 の責務）。本案件は ORD ループに閉じており、INV→ORD の逆引きは行わない。
6. 有効フラグ=FALSE の扱い: ORD・INV ともに 有効フラグ=FALSE の行は全処理でスキップ（CLAUDE.md コーディング規約準拠）。
7. 既存バリデーション色とのクリア順序: validateOrder_ の iBal < 0 色を WARN_RED_BG（#f4cccc）に変更する場合、applyValidationResults_ の errColors リスト（L163）にも #f4cccc を追加しないと、既存の VAL クリアパスで消されない点に注意。ただし Constants.COLORS.WARN_RED_BG は VAL_COLORS.ERROR と同値（#f4cccc）のため、結果的に既存ロジックと整合する（= リストへの追加不要）。念のため実装時に再確認すること。

エッジケース

実データ検証

Phase 1 のコード・スキーマ調査で確認した事項（MCP ライブ検証は別途実施して本セクションに追記する）:

関連ドキュメント

人間が検討すべき事項

実装プロンプト（Claude Code 用）

あなたはGAS会計システム(bizlp-gas-accounting)のシニア開発者です。
案件 MAS-124「31タブ発注残高エイジング＆超過発注アラート」を実装してください。

## 実行前タスク（必読）
- `000_infra/003_contracts.js`: OrderDTO の `発注ステータス` 列挙値（"見積中"|"発注済"|"検収済"）・`終了年月` フォーマット（"YYYY-MM"）・InvoiceDTO の `請求ステータス` 列挙値（"未処理"|"承認済"|"却下"）を確認
- `200_data/202_repository.js`: `OrderRepository.save()` が `writeDtosToSheet_` による全行置換であり、`発注残高(自動計算)` は GAS 管理のため DTO 経由で書き戻しても数式は消えないことを再確認
- `200_data/201_data_validator.js` L447-462 `validateOrder_`: 既存の `iBal < 0` 警告色を `VAL_COLORS.WARNING` から `Constants.COLORS.WARN_RED_BG` に変更
- `400_domain/410_subledger_engine.js`: `processInvoiceApprovals`（L106）/ `processSettlementClearings`（L365）が実体。`runActionA_/runActionB_` は**実在しない**ため、末尾フックではなく独立メニュー呼び出しを採用
- `templates/operations_sidebar.html` L71-76 の `<div class="section"><h3>⚙️ メンテナンス</h3>` を Read し、`runDataValidation` ボタン直後にメニュー追加
- 仕様書の「実データ検証」セクションで確定した `発注ステータス` 実在値のみを使用。"完納" が MCP で未確認の場合はステータス自動更新を**ドライラン（候補表示のみ）**に留める

## 修正対象ファイル
1. `400_domain/411_order_aging.js` — **新規作成**。`OrderAgingService` と `runOrderAging()` を実装
2. `200_data/201_data_validator.js` — `validateOrder_` の `iBal < 0` の色を `Constants.COLORS.WARN_RED_BG` に変更（1行）
3. `templates/operations_sidebar.html` — 「⚙️ メンテナンス」セクションに発注エイジングボタンを1行追加
4. `900_test/901_test_runner.js` — エイジング計算・候補抽出のユニットテストを追加

## 実装内容
仕様書「修正方針」のデータフロー手順 1〜7 に厳密に従って実装する:
1. `LockService.getScriptLock()` + `lock.waitLock(30000)` を `try/finally` で取得
2. `OrderRepository.findAll()` で全 ORD DTO 取得
3. `InvoiceRepository.findAll()` から `Map<ORD_ID, InvoiceDTO[]>` を構築（有効フラグ=TRUE かつ `請求ステータス !== "却下"` のみ）
4. 全 ORD を走査し、①超過発注 / ②エイジング / ③ステータス自動更新候補 を同時判定（`有効フラグ=FALSE` と `発注ステータス="検収済"` はスキップ）
5. `bg` / `notes` 2 次元配列を構築して `sheet.getRange(1,1,rowCount,colCount).setBackgrounds(bg)` / `setNotes(notes)` で一括適用。既存色は `applyValidationResults_` 型のパターンで保持
6. ステータス自動更新候補があれば `ui.alert(..., ButtonSet.YES_NO)` で確認 → YES のみ DTO 書き換え → `OrderRepository.save(dtos)` → `Utils.auditLog` で各 ORD を記録
7. `Utils.toastResult('runOrderAging', ..., 8)` で完了通知

## 制約
- `発注ステータス` の更新値は仕様書「実データ検証」で確定した実在値のみ使用。MCP 未確認で "完納" が実在しない場合は候補表示のみ（save 呼ばない）
- `LockService.getScriptLock()` は `try { lock.waitLock(30000); ... } finally { lock.releaseLock(); }` パターンを厳守
- データ書き込みは `OrderRepository.save()` 経由のみ。セル直接書き込みは `setBackgrounds()` / `setNotes()` による装飾のみ許可（データ変更は不可）
- 列インデックスのハードコード禁止。`headers.indexOf('フィールド名')` または DTO プロパティアクセス（`dto['税込金額_発注']`）を使用
- 金額フィールドは必ず `Utils.parseAmt()` 経由で数値化
- 日付フィールドは `Utils.parseDateToYm()` で `"YYYY-MM"` に正規化して比較
- `getLastColumn()` 使用禁止（failure_patterns.md #21）。列数は headers.length または DDL 定数から取得
- `発注残高(自動計算)` は GAS 管理のため、save() 前に DTO 内の該当値を `Utils.parseAmt` で正規化（空文字のまま書くと NaN 化するリスク）

## エッジケース
仕様書「エッジケース」テーブルを全件実装で担保すること。特に:
- `終了年月` 空欄 → エイジング対象外（警告なし）
- `発注ステータス="検収済"` → 全チェック対象外
- `請求ステータス="却下"` の INV → 集計母数から除外
- `請求ステータス="未処理"` の INV を含む ORD → 候補抽出（③）から除外、エイジング（②）は通常通り
- 超過発注（`発注残高 < 0`）→ `WARN_RED_BG` でハイライト
- 滞留月数の色分け: 1ヶ月以内＝`#FFF2CC`、2ヶ月以内＝`#FCE5CD`、3ヶ月以内＝`#F4CCCC`、3ヶ月超＝`#EA9999`

## 動作確認
1. `npm run push:dev` でデプロイ
2. 開発用スプレッドシートのサイドバー「⚙️ メンテナンス」→「🗂️ 発注エイジング＆超過検知」を実行
3. `発注残高(自動計算) < 0` の ORD が 🔴 `#f4cccc` でハイライトされることを確認
4. `終了年月` を 3 ヶ月前に設定した ORD が濃赤でハイライトされることを確認
5. `終了年月` 空欄の ORD がエイジング警告対象外であることを確認
6. `発注残高=0` かつ全 INV 承認済の ORD が候補ダイアログに列挙されることを確認
7. YES 選択後、`31_wrk_order` の `発注ステータス` が確定値に更新されていることを確認
8. `98_audit_log` に各 ORD の遷移記録が追記されていることを確認
9. `Utils.toastResult` の完了通知が表示されることを確認
10. 処理中に Action A (`processInvoiceApprovals`) を別タブから実行 → `LockService` で待機されることを確認
11. `OrderRepository.save()` 実行後に `発注残高(自動計算)` の値が保持されていることを確認
12. `900_test/901_test_runner.js` の新規テストケースが全て PASS すること

### 拡張思考の使用状況
| フェーズ | 拡張思考 | 備考 |
|---------|:--------:|------|
| Phase 1（設計） | あり | ファイル調査・固有名詞確定・配置レイヤー判断 |
| Phase 2（清書） | なし | Phase 1 確定内容の書き下し |

推奨実行モデル

変更履歴

仕様書作成プロンプト

<instruction>
【タイムアウト回避・実行原則（v1.7・必ず遵守すること）】
1. **拡張思考の使い分け**: Phase 1（設計）では拡張思考をフル活用し、ファイル名形式・エッジケース一覧・Step 分割粒度・固有名詞（関数名/シート名/列名/行番号）を完全に確定させる。Phase 2（清書）の各 Step 内では拡張思考を最小限に抑え、Phase 1 で確定済みの内容の書き下しに徹する。出力途中で再考しない。
2. **テキスト報告の禁止**: 「〜を作成します」等の text のみで tool_use なしに turn を終了しない。説明は 1 文以内。直ちに tool を呼ぶ。
3. **4-5 分割の Write/Edit 実行**: Step 2-1(骨格 ~20行) / Step 2-2(概要〜注意事項 ~300行) / Step 2-3a(エッジケース〜人間検討事項 ~200行) / Step 2-3b(実装プロンプト〜変更履歴 ~250行) / Step 2-4(`<details>` プロンプト全文記録) に分割。1 回の Write/Edit は約 300 行以内。
4. **各 Step で何を書くかを具体指示**: Phase 1 で設計を完全に確定させ、Phase 2 実行時に設計判断を再考しない。

======================================================================
あなたはGAS会計システム(bizlp-gas-accounting)のシニア開発者兼仕様書ライターです。
案件 S-52「31タブ発注残高エイジング＆超過発注アラート」の開発仕様書を作成してください。
作成した仕様書は `docs/_config.json` の `nav` 配列の適切なセクションにも必ず追記してください。

---

## Phase 1: 実行前タスク（テキスト報告禁止。即座にツール実行）

以下を **全て Read/Grep ツールで調査** してから Phase 2 に進む。推測・記憶で記述しない。
**Grep は「どこにあるか」の発見まで。「どう書くか」の判断は必ず Read。**

### 1-A: 案件定義の読み込み
- `docs/_internal/TODO_future.md` — S-52 の「案件名」「概要」「期待される効果」「人間が検討すべき事項」を取得

### 1-B: プロジェクト規約の読み込み
- `CLAUDE.md` — ファイル番号体系・コーディング規約（列参照ルール、シート書き込み位置など）・会計ロジックルールを確認

### 1-C: 既存仕様書テンプレートの読み込み
- `docs/dev/dev_mas-085_consistency_check.md` — 整合性チェック・アラート系の実装パターンを把握する

### 1-D: 関連コードの調査（以下を順番に Read し、仕様書に書く全固有名詞を Read した内容のみから引用すること）

1. **`000_infra/003_contracts.js`**
   - `OrderDTO` の全プロパティ名・型・JSDoc コメントを確認
     - `発注ステータス` の列挙値（"見積中" / "発注済" / "検収済" 以外の値が実在するか）
     - `発注残高(自動計算)` フィールドの扱い（GAS 書き込みか Sheets 数式か後述 MCP で確認）
     - `開始年月` / `終了年月` のフォーマット（"YYYY-MM" であること）
     - `税抜金額_発注` / `税込金額_発注` のどちらを超過判定に使うか
     - ⚠️ **「完納」ステータスは JSDoc に記載なし**。Read で実定義を確認し、存在しない場合は後述 1-E の MCP 確認結果に委ねる
   - `InvoiceDTO` の全プロパティ名・型・JSDoc コメントを確認
     - `請求ステータス` の列挙値（"承認済" の表記が正確か）
     - `親発注ID(ORD)` のプロパティ名（Map キーに使用する）
     - 計上済金額の算出に使うフィールド（`税抜金額_計画` / `税込金額_計画` のどちらか）
     - ⚠️ `契約終了年月` という名称は OrderDTO に存在しない。正しくは `終了年月` であることを Read で確認

2. **`000_infra/002_constants.js`**
   - `SHEET_DEFAULTS` の `31_wrk_order` エントリの `defaults` オブジェクトでフィールド名の正確な文字列を確認
   - `ID_PREFIX_MAP` の `31_wrk_order` エントリ（`ORD_` プレフィックス）を確認

3. **`000_infra/004_utils.js`**
   - `Utils.parseDateToYm(val)` の引数型と戻り値を確認
   - `Utils.auditLog(operation, targetSheet, targetId, targetCol, funcName, beforeValue, afterValue, note)` の引数シグネチャを正確に把握
   - `Utils.toastResult(funcName, message, duration)` の引数シグネチャを確認
   - `Utils.logInfo` / `Utils.logError` の使用パターンを確認

4. **`200_data/202_repository.js`**
   - `OrderRepository.findAll()` の戻り値型 `{ headers: string[], dtos: OrderDTO[] }` を確認
   - `OrderRepository.save(dtos)` が `writeDtosToSheet_()` を呼ぶ**全行置換**であることを確認
     - ⚠️ `発注残高(自動計算)` が Sheets 数式管理の場合、`save()` で上書きすると数式が消える。1-E の MCP 確認が必須
   - `InvoiceRepository.findAll()` の戻り値型を確認

5. **`200_data/201_data_validator.js`**
   - 既存バリデータの関数構造・呼び出し方・配置パターンを把握
   - 今回の機能（エイジング計算・超過判定・ステータス更新）がデータアクセス層（`200_data/`）に属するか、ドメイン層（`400_domain/`）に属するかを判断するための根拠として使う

6. **`400_domain/410_subledger_engine.js`**
   - `SubledgerService` の公開 API と内部プライベート関数の全一覧を確認
   - `runActionA_` / `runActionB_` が**実在するか**と、実在する場合の末尾フック挿入に適した行番号を特定
   - ⚠️ 実在しない場合は、代替フック方法（メニュー直接呼び出し関数として独立実装など）を仕様書に記載する
   - `LockService` の利用有無と、既存ロックとの競合リスクを確認

7. **`100_config/101_sys_config.js`**
   - `onOpen()` のメニュー構造を Read し、今回の機能をどのメニュー区分に追加すべきかを判断
   - ⚠️ メニュー名・区分名は Read した実在する文字列のみ引用。造語禁止

8. **`docs/_internal/failure_patterns.md`**
   - #16（合算マッチ時の matched=true ロック ＝ 今回はステータス更新済み発注の二重更新防止に適用）
   - #18-#20（仕様書固有名詞の誤記防止：データ構造の型・フィールド名は Read で裏取り済みのもののみ）
   - #21（`getLastColumn()` 使用禁止・月列は固定）

### 1-E: 実データ検証（MCP で確認）
- `31_wrk_order` の「発注ステータス」列の実格納値一覧（"完納" が存在するか確認）
- `32_wrk_invoice` の「請求ステータス」列の実格納値（"承認済" の表記確認）
- `31_wrk_order` の「発注残高(自動計算)」列が Sheets 数式管理か GAS 書き込みかを確認（`save()` で上書きしてよいか判断）
- `31_wrk_order` の「終了年月」列の実際のデータ形式（空欄・YYYY-MM・その他）を確認

---

## Phase 2: 仕様書の分割作成

**出力先**: `docs/dev/dev_mas-124_order_aging_alert.md`

### Step 2-1: 骨格の作成 (Write, ~20行)
（セクション見出しのみ。本文は空で可）

### Step 2-2: 概要〜注意事項の追記 (Edit, ~300行)
（概要テーブル / 目的 / 現在のコード / 修正方針 / 影響範囲 / 注意事項）

### Step 2-3a: エッジケース〜人間が検討すべき事項の追記 (Edit, ~200行)
（エッジケーステーブル / 実データ検証 / 関連ドキュメント / 人間が検討すべき事項）

### Step 2-3b: 実装プロンプト〜変更履歴の追記 (Edit, ~250行)
（実装プロンプト / 推奨実行モデル / 変更履歴）

### Step 2-4: 仕様書作成プロンプトの記録 (Edit)
（末尾に `<details>` で本プロンプト全文を転記）

---

## Phase 3: `_config.json` 追記・changelog 追記・コミット

### 3-1: `_config.json` に登録
`docs/_config.json` を Read して `nav` 配列の既存エントリを確認してから、適切なセクションに追記:
セクション判定: バリデーション・アラート系 → §E.2。

### 3-2: changelog 追記
`docs/_internal/changelog.md` のヘッダー直後に追記

### 3-3: コミット＆プッシュ
```bash
git add docs/dev/dev_mas-124_order_aging_alert.md docs/_internal/changelog.md docs/_config.json
git commit -m "docs: MAS-124 31タブ発注残高エイジング＆超過発注アラートの開発仕様書を作成"
git push -u origin <現在のブランチ>
```
</instruction>