docs: Botトークフロー再設計の実装完了を記録

Pleasanter/健康診断管理/docs/n8n/2026-09-10-bot-flow-redesign-plan.md

@@ -2,6 +2,8 @@
 
 > **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
 
+**2026-09-11更新**: 着手前に本番HC-WAへ2件の緊急バグ修正が入った(下記Global Constraints・Task0参照)。全ワークフローは現在誤送信対策で`inactive`化されている。本計画のPUT作業自体はactive/inactiveに関係なく実施できるが、Task2/3/4の「実機トークで確認」ステップの直前に対象ワークフローを一時activateする判断をユーザーに仰ぐこと。
+
 **Goal:** 健康診断管理フェーズ2のLINEWORKS Bot対話フローを、承認済み仕様書(`2026-09-10-bot-flow-redesign.md`)通りに再構築する。「健康診断メニュー」の呼称統一、パターンA(受診日時)の分岐変更、パターンB(受診結果確認)の新規実装が中心。
 
 **Architecture:** n8n上で本番稼働中の4ワークフロー(HC-WA/HC-WP/HC-REMINDER/HC-DOC-TIMEOUT)のCodeノードを、Public API(`PUT /api/v1/workflows/{id}`)経由で直接更新する運用。508971(社員別健康診断管理)側は新規Process「自分手配」を追加。DescriptionBの「日時：」行書き換えはn8n(HC-WA)側で行う(Pleasanter Processの値式では動的な文字列組み立てが難しいため)。
@@ -10,6 +12,8 @@
 
 ## Global Constraints
 
+- **【2026-09-11反映済み・消さないこと】HC-WA「署名検証・対象レコード特定」ノード174行目付近**: `resultId: record.ResultId` は `resultId: String(record.ResultId)` に修正済み。resultIdがNumber型のまま渡ると、後段「IF: resultIdあり」ノード(`typeValidation:strict`のstring.notEmpty演算子)が型エラーでワークフロー全体を異常終了させ、Webhookレスポンス未返却→LINEWORKS側リトライ→同一メッセージ重複送信を引き起こすバグの修正。Task2〜4はこのノードを触らないので通常は影響しないが、万一このノードのコードを再取得・再構築する場合は必ずString化を維持すること。
+- **【2026-09-11反映済み・消さないこと】HC-WA「分岐処理・実行・送信」ノード冒頭、`// ==== -1. LINEWORKS自動送信イベント(トーク開始時の"利用開始"等) → 無反応 ====`ブロック(現状142-145行目)**: LINEWORKSがBotとのトーク開始・グループ招待時に自動送信する定型テキスト`"利用開始"`を、ユーザーの実発言と誤認識して無条件応答(「対象の健診情報がありません」「待機状態が不正です」等)を返してしまうバグの修正。対応する「署名検証・対象レコード特定」側の`content.text === "利用開始"`検知ブロックとセット。Task2〜4で「分岐処理・実行・送信」ノードのjsCodeを書き換える際、必ずGET直後の最新コードをベースにし(このブロックを含んだ状態から差分編集する)、コミット済みの古いコードスニペットで丸ごと上書きしないこと。
 - n8n CodeノードはTask Runner環境。`require(...)`でNode.js組み込みモジュールは読めない。グローバルの`crypto`も存在しない(暗号処理が要る場合はpure JS実装で対応、`identity.js`の署名検証で実績あり)。
 - Pleasanter `View.ColumnFilterHash`は列の型で書式が変わる。**リンク型(選択肢が`[[SiteId]]`や`[[Users*]]`)の列は値をJSON配列文字列化(`JSON.stringify([value])`)、通常の自由入力Class列は素の文字列**を渡す。508971の`ClassC`はリンク型(配列形式)、504412の`ClassA`/`Class011`は自由入力(文字列形式)。書式を誤るとフィルタが機能せず全件返る(サイレント障害になるので要注意)。
 - 508971のProcess定義をAPI経由で**ゼロから構築してPUTすると、個別レコード編集画面が全件開けなくなる重大障害**が過去に発生している。新規Process追加時は、Pleasanter画面上で管理者に空のProcessを1件手動登録してもらい、それに対してAPI経由でプロパティを追記する方式のみ許可する。既存Processesを配列ごと構築し直すことは絶対にしない。
@@ -56,6 +60,25 @@ n8n側は全てPublic API経由のPUT更新。ローカルには一時作業フ
 **Interfaces:**
 - Produces: DescriptionBの「日時：」行置換関数`replaceDateLineInDescription(description, newDateText)`の実装(Task 2以降で使う)
 
+- [ ] **Step 0: 2026-09-11緊急修正がHC-WA本番に反映済みであることを確認する**
+
+```bash
+node -e "
+const KEY = '<NodeSrv/apps/n8n/docs/n8n-guide.md 2章のPublic API Key>';
+(async () => {
+  const res = await fetch('https://n8n32.next-hd.net/api/v1/workflows/0i0Ze3Gq0Waof3Fa', { headers: { 'X-N8N-API-KEY': KEY } });
+  const j = await res.json();
+  const seimei = j.nodes.find(n => n.name === '署名検証・対象レコード特定').parameters.jsCode;
+  const bunki = j.nodes.find(n => n.name === '分岐処理・実行・送信').parameters.jsCode;
+  console.log('active:', j.active);
+  console.log('resultId String化:', seimei.includes('resultId: String(record.ResultId)'));
+  console.log('利用開始イベント無視:', bunki.includes('identity.resolveError === \"system_event\"'));
+})();
+"
+```
+
+Expected: `active: false`(HC-WAはユーザー指示で誤送信対策のため停止中)、両方の判定行が`true`。`false`が出た場合は他セッションで別のPUTが入って巻き戻った可能性があるため、作業前に必ずユーザーへ確認する。
+
 - [ ] **Step 1: 513409のDescriptionBを取得し、実際の改行・文字コードを確認する**
 
 ```bash
@@ -309,7 +332,9 @@ const fs = require('fs');
 
 - [ ] **Step 2: `_branch_next.js`の該当箇所を書き換える**
 
-180-191行目(旧):
+**注意**: 下記の行番号(185-196行目)は2026-09-11時点の本番コード基準。Step1で取得した`_branch_next.js`は先頭に2026-09-11追加の「-1. LINEWORKS自動送信イベント」ブロック(9行)を含むため、行番号でなく下記コード文字列で該当箇所を検索して置換すること。このブロック自体(`identity.resolveError === "system_event"`の判定)と、その前の「0. 対象者解決エラー」ブロックは一切変更しない。
+
+185-196行目相当(旧):
 ```javascript
   if (text === "健康診断について") {
     const categoryActions = [];
@@ -364,6 +389,22 @@ const fs = require('fs');
 
 Expected: `200` とタイムスタンプ。
 
+- [ ] **Step 3.5: HC-WAを一時activateする(ユーザー確認必須)**
+
+現在HC-WAは誤送信対策で`inactive`。実機トーク確認にはWebhookが動く必要があるため、activateしてよいかユーザーに確認してから実施する:
+
+```bash
+node -e "
+const KEY = '<NodeSrv/apps/n8n/docs/n8n-guide.md 2章のPublic API Key>';
+(async () => {
+  const res = await fetch('https://n8n32.next-hd.net/api/v1/workflows/0i0Ze3Gq0Waof3Fa/activate', { method: 'POST', headers: { 'X-N8N-API-KEY': KEY } });
+  console.log((await res.json()).active);
+})();
+"
+```
+
+Expected: `true`。以降のタスクでも実機確認の間はactiveなままでよい(Task6完了まで継続)。
+
 - [ ] **Step 4: 野木さん(513409、現在Status=310)の実機トークで確認する**
 
 固定メニュー「健康診断について」をタップし、「受診日時について」「受診結果について」の2択(Status=310なので両方出る)が表示されることを確認する。まだ中身は未実装なので、押しても`if`に一致せず`buildResult("noop")`扱いになる(何も返らない)想定。ここでは**ボタンの見た目だけ**確認する。
@@ -373,7 +414,7 @@ Expected: `200` とタイムスタンプ。
 ## Task 3: HC-WA branch.js — 受診日時について(パターンA)
 
 **Files:**
-- Modify: 同上ノード。193-214行目(旧`健診日程`ブロック)と244-280行目(`schedule_confirm`状態)を全面改修。
+- Modify: 同上ノード。旧`健診日程`ブロック(Task2時点で198-219行目相当)と`schedule_confirm`状態(249-285行目相当)を全面改修。**行番号は毎回Step1で取得する最新コードに合わせて実装者が特定すること**(2026-09-11追加の冒頭ブロック分だけ既存計画記載よりずれている)。
 
 **Interfaces:**
 - Consumes: Task1で追加したProcessId(`自分手配`、`PROCESS_ID.SELF_ARRANGE`として定義)、Task0で検証した`replaceDateLineInDescription`/`formatDateTimeSlash`
@@ -638,7 +679,7 @@ cd "/c/Users/k.nogi/#GitHub/ken_nogi/dev" && rm -f _wf_hcwa.json _branch_next.js
 ## Task 4: HC-WA branch.js — 受診結果について(パターンB)
 
 **Files:**
-- Modify: 同上ノード。216-239行目(旧`受診・再検査報告`/`診断書提出`ブロック)、301-309行目(`attendance_310`のyesno_confirm処理)を全面改修。新規状態`retest_choice`・`reschedule_input`を追加。
+- Modify: 同上ノード。旧`受診・再検査報告`/`診断書提出`ブロック(Task2時点で221-244行目相当)、`attendance_310`のyesno_confirm処理(306-314行目相当)を全面改修。新規状態`retest_choice`・`reschedule_input`を追加。**行番号は毎回Step1で取得する最新コードに合わせて実装者が特定すること**(2026-09-11追加の冒頭ブロック分だけ既存計画記載よりずれている)。
 
 **Interfaces:**
 - Consumes: Task3の`buildHospitalContactMessage`、`replaceDateLineInDescription`、`formatDateTimeSlash`、`parseDateInput`
@@ -947,8 +988,50 @@ git commit -m "docs(healthcheck): Botトークフロー再設計の実装完了
 
 ---
 
+## Task 7: 全Webhookの本番反映判断
+
+Task1〜6完了後、健康診断関連の全Webhook(HC-WA/HC-SETUP/HC-FORM-SYNC/HC-WP、いずれも2026-09-11時点で`inactive`)を本番稼働状態に戻すかどうかの最終判断。
+
+**Files:** なし(n8n active状態の変更のみ)
+
+- [ ] **Step 1: 健康診断関連ワークフロー全件のactive状態を一覧確認する**
+
+```bash
+node -e "
+const KEY = '<NodeSrv/apps/n8n/docs/n8n-guide.md 2章のPublic API Key>';
+(async () => {
+  const res = await fetch('https://n8n32.next-hd.net/api/v1/workflows?limit=100', { headers: { 'X-N8N-API-KEY': KEY } });
+  const j = await res.json();
+  for (const w of j.data) if (w.name.startsWith('HC-')) console.log(w.id, w.name, 'active=', w.active);
+})();
+"
+```
+
+- [ ] **Step 2: ユーザーへ本番反映(activate)可否を確認する**
+
+Task1〜6の実機検証(野木さん513409、全シナリオ)がすべて成功していることを前提に、「HC-WA/HC-SETUP/HC-FORM-SYNC/HC-WPを本番activateしてよいか」をユーザーへ確認する。HC-REMINDER/HC-DOC-TIMEOUTは元々2026-09-07時点から「実運用開始タイミングで別途判断」の対象(このタスクのスコープ外、ユーザーが別途判断)。
+
+- [ ] **Step 3: 承認を得たワークフローのみactivateする**
+
+```bash
+node -e "
+const KEY = '<NodeSrv/apps/n8n/docs/n8n-guide.md 2章のPublic API Key>';
+const ids = ['0i0Ze3Gq0Waof3Fa', '0jVVF9WGlZrAygXX', 'G2nWfvPCsIKpup60', 'swXfpoDtwZDT3Hwk']; // HC-WA/HC-SETUP/HC-FORM-SYNC/HC-WP
+(async () => {
+  for (const id of ids) {
+    const res = await fetch(\`https://n8n32.next-hd.net/api/v1/workflows/\${id}/activate\`, { method: 'POST', headers: { 'X-N8N-API-KEY': KEY } });
+    const j = await res.json();
+    console.log(j.name, 'active=', j.active);
+  }
+})();
+"
+```
+
+---
+
 ## Self-Review メモ
 
 - Task0で洗い出した4項目は、それぞれTask1 Step4(Process起点Status)、Task3 Step1-3(DescriptionB置換・ResultIdフィルタ書式)、Task4 Step6(ProcessId無し更新の可否)で実際に検証・反映される導線を確保した。
 - 診断書保存フロー・再検査フローのa〜d収集ロジックは仕様書通り「既存のまま変更なし」のため、本計画にタスクを設けていない(意図的な除外)。
 - HC-DOC-TIMEOUTワークフローは今回変更対象外(仕様書に変更点なし)。
+- **2026-09-11追加分**: 着手前にresultId型エラー・"利用開始"イベント無条件応答の2バグを本番HC-WAへ緊急修正済み(Global Constraints・Task0 Step0参照)。この2件のロジックはTask2〜4の改修対象範囲(「健康診断について」以降の分岐)より前段に位置するため、Step1のGET→差分編集という手順を守る限り自然に保持される。Task7で本番activateの最終判断ステップを新設(旧計画にはなかった、全Webhook停止状態からの再開手順が欠けていたため)。