README更新: 全ワークフローのn8nデプロイ完了・フォルダ作成を記録

HC-SUB(7ノード)を既存id XRqcykbG2LuAjGG2へ上書き、HC-WP(5ノード)
を既存id swXfpoDtwZDT3Hwkへ上書き、HC-WA(14ノード)を新規id
0i0Ze3Gq0Waof3Faで作成、いずれもactive化してコントローラーが
直接実行(HTTP 200)。n8nフォルダ「健康診断ワークフロー」
(hOx8WKrdOucllbcU)も作成済み。3ワークフローのフォルダ移動は
transfer APIの制約(別プロジェクト専用+active解除の副作用)により
ユーザーがUIで手動実施する運用に。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

NodeSrv/apps/healthcheck-survey-bot/README.md

@@ -30,8 +30,8 @@ Task 5（processFlow.js）の`getValidationColumnNames`はこの構造（`proces
 
 - ワークフロー `HC-SUB: プロセス実行と案内送信`: `XRqcykbG2LuAjGG2`
   - ファイル: `workflows/hc-sub-run-process-and-notify.json`（Execute Workflow Trigger、入力`{resultId, processId}`）
-  - **プロジェクト全体のn8nワークフロー構築ルール（2026-09-05改訂）に合わせて7ノード構成へ全面リビルド。旧19ノード版（個別キーごとのData Table Getノード×7、HTTP Requestノード×6を並べた構成）を置き換える。** 同じワークフローID`XRqcykbG2LuAjGG2`へのPUTで上書きする想定（デプロイはコントローラーが実施、本タスクではJSON作成・ローカル検証のみ）
+  - **プロジェクト全体のn8nワークフロー構築ルール（2026-09-05改訂）に合わせて7ノード構成へ全面リビルド。旧19ノード版（個別キーごとのData Table Getノード×7、HTTP Requestノード×6を並べた構成）を置き換え、同じワークフローID`XRqcykbG2LuAjGG2`へPUTで上書き済み（2026-09-05、コントローラー実施、HTTP 200）。**
-  - active化済み（Execute Workflow Triggerサブワークフローは呼び出し元から実行可能にするためactive必須、`asKvC5LSVg3q8tuU`と同じ運用）— 再デプロイ後も設定は維持される想定
+  - active化済み（Execute Workflow Triggerサブワークフローは呼び出し元から実行可能にするためactive必須、`asKvC5LSVg3q8tuU`と同じ運用）
   - ノード構成（7ノード、リニア接続）:
     1. `Execute Workflow Trigger`（入力: `resultId`, `processId`）
     2. `Data Table`「設定値一括取得」: `workflow_config_values`（`bNkadTyDgDepYx2p`）を`filters`無し・`returnAll:true`で一括取得（個別キーごとのGetノードを廃止）
@@ -55,12 +55,14 @@ Task 5（processFlow.js）の`getValidationColumnNames`はこの構造（`proces
   - active化済み
   - `X-Api-Key`は`workflow_config_values`の`HEALTHCHECK_WP_API_KEY`と照合。秘密値のハードコードなし
   - 実際のcurl疎通テスト（本番508971書き込み・LINEWORKS実送信を伴う）は未実施。ユーザー確認後に実施する
-  - デプロイ・活性化はサブエージェントのBashサンドボックスが実APIキー使用を一律ブロックしたためコントローラーが直接実行した（詳細: `task-10-report.md`）
+  - デプロイ・活性化はサブエージェントのBashサンドボックスが実APIキー使用を一律ブロックしたためコントローラーが直接実行した（詳細: `task-10-report.md`）。設定値取得もfilter付き単一キーGetから一括取得+Codeフィルタへ変更済み
 
-- ワークフロー `HC-WA: LINEWORKS応答受信`: **ローカルJSON作成のみ、n8n未デプロイ**（id未採番）
+- ワークフロー `HC-WA: LINEWORKS応答受信`: `0i0Ze3Gq0Waof3Fa`
   - ファイル: `workflows/hc-wa-lineworks-response.json`
-  - **プロジェクト全体のn8nワークフロー構築ルール（2026-09-05改訂）に合わせて14ノード構成で全面リビルド。旧60ノード版（個別キーごとのData Table/HTTP Requestノードを積み上げ、awaitInput分岐をSwitch+各分岐に案内送信一式を重複配置した構成）はこのタスクでの再構築に伴い置き換えた。**IF・JWT・Execute Workflow・Data Tableは各ルールに従い専用ノードのままだが、それらは機械的に必要な最小限（IF×2, JWT×1, Execute Workflow×1, Data Table×3）であり、本来Codeノードに集約可能な分岐ロジック・Pleasanter/LINEWORKS API呼び出しはすべて4つのCodeノードに集約した（ブリーフの目安「11ノード」に対し実際は14ノードだが、これはIF/JWT/Execute Workflowを専用ノードに保つというルール自体が要求する固定オーバーヘッドであり、60ノードからの削減という趣旨は達成している）
+  - Webhook: `https://n8n32.next-hd.net/webhook/healthcheck-lineworks-response`（LINE WORKS本体からの直接コールバック、`x-works-signature`検証）
-  - 本タスクの担当範囲はワークフローJSONのローカル作成・検証までで、n8n Public APIの呼び出し（デプロイ・activate）は一切実施していない。コントローラー側での`node scripts/deploy-workflow.js workflows/hc-wa-lineworks-response.json`実行後、実際のワークフローIDをこの行に追記すること
+  - active化済み（2026-09-05、コントローラーが新規デプロイ・activate、HTTP 200）
+  - **プロジェクト全体のn8nワークフロー構築ルール（2026-09-05改訂）に合わせて14ノード構成で全面リビルド。旧60ノード版（個別キーごとのData Table/HTTP Requestノードを積み上げ、awaitInput分岐をSwitch+各分岐に案内送信一式を重複配置した構成）を置き換えた。**IF・JWT・Execute Workflow・Data Tableは各ルールに従い専用ノードのままだが、それらは機械的に必要な最小限（IF×2, JWT×1, Execute Workflow×1, Data Table×3）であり、本来Codeノードに集約可能な分岐ロジック・Pleasanter/LINEWORKS API呼び出しはすべて4つのCodeノードに集約した（ブリーフの目安「11ノード」に対し実際は14ノードだが、これはIF/JWT/Execute Workflowを専用ノードに保つというルール自体が要求する固定オーバーヘッドであり、60ノードからの削減という趣旨は達成している）
+  - LINEWORKS Developer Console側のBot Callback URL設定・疎通テストは未実施。ユーザー確認後に実施する
   - ノード構成（14ノード）:
     1. `Webhook`（`healthcheck-lineworks-response`, `rawBody:true`）
     2. `Data Table`「設定値一括取得」: `workflow_config_values`を`filters`無し・`returnAll:true`で一括取得
@@ -84,3 +86,16 @@ Task 5（processFlow.js）の`getValidationColumnNames`はこの構造（`proces
     ③484184(`LINEWORKS_BOT_MASTER_SITE_ID`)からのBotId解決ロジックはHC-SUBと同じ暫定実装（`SiteSettings.BotIds`または`Processes[].BotId`を仮定）
     ④**LINEWORKSファイル添付（`awaitInput:"file"`分岐）の実処理は未実装。** ファイルダウンロード（`GET /v1.0/bots/{botId}/attachments/{fileId}`）にはLINEWORKS Bot APIのアクセストークンが必要だが、JWT署名は専用のJWTノード（ノード11、action=="send"経路にのみ存在しノード5より後段）でしか行えないため、ノード5内ではトークンを取得する手段がない。現状はこのケースを検出すると`action:"send"`でユーザーに「準備中」メッセージを返し、待機状態は`file`のまま維持する（ユーザーが詰まらないための安全側実装）。実装するにはグラフ構成の見直し（ファイル受信専用のJWT/Tokenペアを追加する等）が必要で、フォローアップタスクで対応すること
   - 設計上の注記: HC-SUB（Task 9）が`healthcheck_bot_state`に保存する`pendingProcesses`は`{processId, label, tooltip}`のみで`ValidateInputs`を持たないため、none分岐での`classifyAwaitInput`実行時はHC-WA内で`サイト設定取得`(getsite)を再実行し、ProcessId一致でフルのProcess定義を引き直す設計にした（Task 9側のファイルは変更していない）
+
+## n8nフォルダ
+
+- フォルダ `健康診断ワークフロー`: `hOx8WKrdOucllbcU`（projectId `LOcxF69Gm4PvnkqA`配下に2026-09-05作成）
+- HC-SUB/HC-WP/HC-WAの3ワークフローをこのフォルダへ移動する予定だが、Public APIの`/workflows/{id}/transfer`は別プロジェクトへの移動専用（同一プロジェクト内移動は拒否される）で、実行するとactive状態が解除される副作用があるため、**ユーザーがn8n UI上で手動ドラッグして移動する**運用にした（コントローラーからは未実施）
+
+## workflow_config_values 追加登録キー（2026-09-05、healthcheck-survey-bot用）
+
+既存の`workflow_config_values`（`bNkadTyDgDepYx2p`、org-master-sync用と共用）に以下を追加登録済み:
+- `LW_BOT_CLIENT_ID` / `LW_BOT_CLIENT_SECRET` / `LW_BOT_SERVICE_ACCOUNT`（LINEWORKS通知送信ワークフローと同じBot認証情報）
+- `HEALTHCHECK_SITE_ID`（508971）/ `LINEWORKS_BOT_MASTER_SITE_ID`（484184）/ `HEALTHCHECK_DATA_TABLE_ID`（`jqMDa2YZTI4f0iQ7`）
+- `HEALTHCHECK_WP_API_KEY`（HC-WP Webhook認証用に新規生成）
+- `LINEWORKS_BOT_SECRET`（署名検証用。値は現状プレースホルダー`UNSET_PENDING_BOT_CALLBACK_CONFIRMATION`。LINEWORKS Developer ConsoleでBot Callback URL設定時に実際のBot Secretへ更新が必要）