improve(tts-voice): use spawnSync args to avoid shell quoting issues

2026-03-13 12:02:57 +08:00
14 changed files with 22 additions and 572 deletions
--- a/ProjectManager/README.md
+++ b/ProjectManager/README.md
@@ -1,12 +0,0 @@
 # OpenClaw Project Package
 此資料夾為可直接匯入或參考的原始檔案結構，包含：
 - `skills/`：5 個 OpenClaw skills
 - `rules/`：附件、文件編號、SOP、工作記錄模板
 - `dashboards/`：專案總覽
 - `projects/`：2 個主專案的 `project.yaml`
 ## 主專案
 - `P-ONLINE-DOC-AGENT`
 - `P-ETL-VISUAL-PLATFORM`
--- a/ProjectManager/dashboards/projects-overview.md
+++ b/ProjectManager/dashboards/projects-overview.md
@@ -1,30 +0,0 @@
 # Projects Overview
 ## 主專案總覽
 | Project ID | 名稱 | 狀態 | 進度 | 下一步 |
 |---|---|---:|---:|---|
 | P-ONLINE-DOC-AGENT | Agent 操作線上文件系統 | active | 25% | 建立 EFLOW 附件規則 |
 | P-ETL-VISUAL-PLATFORM | ETL 資料庫轉換可視化網頁 | active | 35% | 建立 SP 與目標欄位 mapping v1 |
 ## 子專案總覽
 ### P-ONLINE-DOC-AGENT
 | Subproject ID | 名稱 | 狀態 | 備註 |
 |---|---|---|---|
 | SP-OFFICIAL-DOC | 線上公文操作 | doing | 建立 SOP v1 |
 | SP-EFLOW | EFLOW 操作 | doing | 整理送件與附件流程 |
 | SP-FORMBUILD | FORMBUILD 操作 | todo | 尚待蒐集畫面與欄位 |
 | SP-ATTACHMENT-RULES | 附件規則 | doing | 定義資料夾與命名 |
 | SP-DOC-ID-RULES | 文件編號規則 | todo | 定義 CASE 與系統編號 |
 ### P-ETL-VISUAL-PLATFORM
 | Subproject ID | 名稱 | 狀態 | 備註 |
 |---|---|---|---|
 | SP-ETL-PIPELINE | ETL 流程整理 | doing | 蒐集流程與來源資料 |
 | SP-DB-SP-ANALYSIS | SP 分析 | doing | 匯整 SP 清單 |
 | SP-TARGET-FIELD-MAPPING | 目標欄位 mapping | todo | 建立欄位對照表 |
 | SP-LLM-DIFF-CHECK | LLM 差異比對 | todo | 定義比較規則 |
 | SP-VISUAL-WEB | 可視化頁面 | todo | 定義顯示模組 |
--- a/ProjectManager/projects/P-ETL-VISUAL-PLATFORM/project.yaml
+++ b/ProjectManager/projects/P-ETL-VISUAL-PLATFORM/project.yaml
@@ -1,13 +0,0 @@
 project_id: P-ETL-VISUAL-PLATFORM
 name: ETL 資料庫轉換可視化網頁
 status: active
 objective: >-
  建立 ETL 資料庫轉換可視化網頁，並以 LLM 協助比對 Stored Procedure 與目標文件欄位差異。
 current_phase: analysis
 next_action: 建立 SP 與目標欄位 mapping 表 v1
 subprojects:
  - SP-ETL-PIPELINE
  - SP-DB-SP-ANALYSIS
  - SP-TARGET-FIELD-MAPPING
  - SP-LLM-DIFF-CHECK
  - SP-VISUAL-WEB
--- a/ProjectManager/projects/P-ONLINE-DOC-AGENT/project.yaml
+++ b/ProjectManager/projects/P-ONLINE-DOC-AGENT/project.yaml
@@ -1,14 +0,0 @@
 project_id: P-ONLINE-DOC-AGENT
 name: Agent 操作線上文件系統
 status: active
 objective: >-
  建立一套可由 Agent 依 SOP 操作的線上文件流程，涵蓋線上公文、EFLOW、FORMBUILD，
  並整合附件規則、文件編號規則與工作記錄。
 current_phase: definition
 next_action: 建立 EFLOW 附件規則與操作步驟 v1
 subprojects:
  - SP-OFFICIAL-DOC
  - SP-EFLOW
  - SP-FORMBUILD
  - SP-ATTACHMENT-RULES
  - SP-DOC-ID-RULES
--- a/ProjectManager/rules/attachment-filing-rules.md
+++ b/ProjectManager/rules/attachment-filing-rules.md
@@ -1,27 +0,0 @@
 # 附件歸檔規則
 ## 目錄結構
 ```text
 attachments/
  official-doc/
    DOC-YYYY-NNN/
  eflow/
    EFL-YYYY-NNN/
  formbuild/
    FBD-YYYY-NNN/
 ```
 ## 檔名格式
 `[文件編號]_[附件類型]_[版本]_[日期].[副檔名]`
 ### 範例
 - `DOC-2026-001_申請書_v1_2026-03-12.pdf`
 - `EFL-2026-003_核准函_v2_2026-03-12.pdf`
 ## Agent 上傳前檢查
 - 是否有文件編號
 - 是否放在正確資料夾
 - 檔名是否正確
 - 版本是否正確
 - 是否缺少必要附件
--- a/ProjectManager/rules/doc-id-convention.md
+++ b/ProjectManager/rules/doc-id-convention.md
@@ -1,20 +0,0 @@
 # 文件編號規則
 ## 系統文件編號
 - 線上公文：`DOC-YYYY-NNN`
 - EFLOW：`EFL-YYYY-NNN`
 - FORMBUILD：`FBD-YYYY-NNN`
 ## 跨系統案件編號
 - `CASE-YYYY-NNN`
 ## 範例
 - `CASE-2026-015`
  - `DOC-2026-021`
  - `EFL-2026-009`
 ## 規則
 1. 新建文件前先判斷系統類型
 2. 若屬同一案件，優先掛既有 CASE-ID
 3. 所有附件檔名必須以前述文件編號開頭
 4. 文件記錄中需保留 CASE 與系統文件編號的對應
--- a/ProjectManager/rules/web-operation-sop.md
+++ b/ProjectManager/rules/web-operation-sop.md
@@ -1,40 +0,0 @@
 # Web Operation SOP Template
 ## 系統名稱
 - 線上公文 / EFLOW / FORMBUILD
 ## 操作目的
 - 例如：建立新案件、送件、補附件、更新欄位
 ## 前置資料
 - 帳號/登入條件
 - 文件編號
 - CASE-ID（若有）
 - 附件清單
 - 欄位資料
 ## 操作步驟
 1. 進入系統
 2. 開啟目標頁面
 3. 輸入或確認必要欄位
 4. 上傳附件
 5. 執行送出或儲存
 6. 確認結果
 ## 上傳附件檢查
 - 路徑：
 - 檔名：
 - 版本：
 - 是否齊全：
 ## 結果記錄
 - 成功 / 失敗 / 阻塞
 - 畫面狀態
 - 文件編號
 - 下一步
 ## 常見錯誤
 - 登入失敗
 - 欄位缺漏
 - 附件格式不符
 - 權限不足
--- a/ProjectManager/rules/worklog-format.md
+++ b/ProjectManager/rules/worklog-format.md
@@ -1,25 +0,0 @@
 # Worklog Format
 ## 日期
 - YYYY-MM-DD
 ## 所屬主專案
 - P-ONLINE-DOC-AGENT / P-ETL-VISUAL-PLATFORM
 ## 所屬子專案
 - 例如：SP-EFLOW
 ## 本次完成
 - 
 ## 本次阻塞
 - 
 ## 使用文件 / 附件
 - 
 ## 文件編號 / CASE-ID
 - 
 ## 下一步
 - 
--- a/ProjectManager/skills/attachment-filing-rules/SKILL.md
+++ b/ProjectManager/skills/attachment-filing-rules/SKILL.md
@@ -1,62 +0,0 @@
 ---
 name: attachment-filing-rules
 description: 用於規範不同線上系統所需附件的資料夾放置、命名、版本與 Agent 取用方式。
 ---
 # Purpose
 本 skill 用來統一附件管理，讓 Agent 能穩定找到正確檔案並完成上傳。
 # Scope
 適用系統：
 - 線上公文
 - EFLOW
 - FORMBUILD
 # Folder Structure
 ```text
 attachments/
  official-doc/
    DOC-YYYY-NNN/
  eflow/
    EFL-YYYY-NNN/
  formbuild/
    FBD-YYYY-NNN/
 ```
 # File Naming Convention
 格式：
 `[文件編號]_[附件類型]_[版本]_[日期].[副檔名]`
 範例：
 - `DOC-2026-001_申請書_v1_2026-03-12.pdf`
 - `EFL-2026-003_核准函_v2_2026-03-12.pdf`
 - `FBD-2026-007_附件清單_v1_2026-03-12.xlsx`
 # Rules
 ## 1. 上傳前檢查
 Agent 上傳附件前必須確認：
 1. 有文件編號
 2. 位於正確系統資料夾
 3. 檔名格式正確
 4. 版本號正確
 5. 是最新檔案
 6. 必要附件已齊全
 ## 2. 禁止事項
 - 不可上傳檔名不明或臨時檔
 - 不可上傳無版本資訊之重複檔案
 - 不可跨系統誤用資料夾中的附件
 ## 3. 回應格式
 當被要求尋找或準備附件時，回應：
 - 系統類型
 - 文件編號
 - 預期附件類型
 - 建議資料夾路徑
 - 檔名檢查結果
 - 缺漏項目
--- a/ProjectManager/skills/doc-id-convention/SKILL.md
+++ b/ProjectManager/skills/doc-id-convention/SKILL.md
@@ -1,54 +0,0 @@
 ---
 name: doc-id-convention
 description: 用於規範線上公文、EFLOW、FORMBUILD 的文件編號與跨系統案件識別方式。
 ---
 # Purpose
 本 skill 用來讓文件、附件、案件、流程之間能一致對應。
 # ID Types
 ## 1. 系統文件編號
 - 線上公文：`DOC-YYYY-NNN`
 - EFLOW：`EFL-YYYY-NNN`
 - FORMBUILD：`FBD-YYYY-NNN`
 範例：
 - `DOC-2026-001`
 - `EFL-2026-014`
 - `FBD-2026-007`
 ## 2. 案件編號（跨系統）
 若同一件事情會跨多個系統，建立案件編號：
 - `CASE-YYYY-NNN`
 範例：
 - `CASE-2026-015`
  - `DOC-2026-021`
  - `EFL-2026-009`
 # Rules
 ## 1. 新建文件
 - 先判斷系統類型
 - 分配對應前綴編號
 - 確認是否屬於既有 CASE
 ## 2. 附件命名
 所有附件檔名必須以前述文件編號開頭。
 ## 3. 記錄關聯
 若文件跨系統，必須明確記錄：
 - CASE-ID
 - 各系統文件編號
 - 關聯說明
 # Response Format
 當需要建立或查詢文件編號時，輸出：
 - 系統類型
 - 是否已有 CASE-ID
 - 建議文件編號
 - 關聯文件
 - 建議資料夾名稱
--- a/ProjectManager/skills/etl-visual-project/SKILL.md
+++ b/ProjectManager/skills/etl-visual-project/SKILL.md
@@ -1,76 +0,0 @@
 ---
 name: etl-visual-project
 description: 用於管理 ETL 資料庫轉換可視化網頁專案，並包含 SP 分析、目標欄位 mapping 與 LLM 差異比對。
 ---
 # Purpose
 此 skill 用於處理：
 - ETL 資料流程整理
 - Stored Procedure 分析
 - 目標文件欄位 mapping
 - LLM 比較 SP 與目標欄位差異
 - 可視化網頁的需求與模組規劃
 # Project
 主專案：
 `P-ETL-VISUAL-PLATFORM`
 子專案：
 - `SP-ETL-PIPELINE`
 - `SP-DB-SP-ANALYSIS`
 - `SP-TARGET-FIELD-MAPPING`
 - `SP-LLM-DIFF-CHECK`
 - `SP-VISUAL-WEB`
 # Core Objective
 建立一套能呈現 ETL 資料庫轉換流程的可視化網頁。
 # Branch Objective
 使用 LLM 比較：
 - Stored Procedure 輸出或邏輯
 - 目標文件定義的欄位
 - 欄位差異與缺漏
 - 型別差異
 - 命名差異
 - 規則差異
 # Workflow
 ## 1. 資料蒐集
 - 蒐集 SP 清單
 - 蒐集目標文件欄位定義
 - 蒐集資料表與 ETL 流向
 ## 2. Mapping
 - 建立欄位對照表
 - 標記來源欄位、目標欄位、轉換規則
 ## 3. LLM Diff Check
 - 比較 SP 欄位與目標文件欄位
 - 輸出缺漏、命名不一致、型別不一致
 ## 4. Visual Web
 - 定義頁面模組
 - 呈現流程圖、欄位 mapping、差異報表
 # Standard Output
 每次回應時，輸出：
 1. 所屬子專案
 2. 本次目標
 3. 所需輸入資料
 4. 產出物
 5. 差異或阻塞
 6. 下一步
 # Example Tasks
 - 匯出 SP 欄位清單
 - 建立目標文件欄位表
 - 建立 mapping 表 v1
 - 用 LLM 產出欄位差異報告
 - 設計 ETL 可視化頁面需求草稿
--- a/ProjectManager/skills/online-doc-agent-ops/SKILL.md
+++ b/ProjectManager/skills/online-doc-agent-ops/SKILL.md
@@ -1,88 +0,0 @@
 ---
 name: online-doc-agent-ops
 description: 用於協助 Agent 操作線上文件系統，包括線上公文、EFLOW、FORMBUILD，並依 SOP、附件規則、文件編號規則執行。
 ---
 # Purpose
 此 skill 用於管理與執行以下系統的 Agent 操作：
 - 線上公文
 - EFLOW
 - FORMBUILD
 # Supported Scope
 ## 主專案
 `P-ONLINE-DOC-AGENT`
 ## 子專案
 - `SP-OFFICIAL-DOC`
 - `SP-EFLOW`
 - `SP-FORMBUILD`
 - `SP-ATTACHMENT-RULES`
 - `SP-DOC-ID-RULES`
 # Execution Rules
 ## 1. 操作前必做檢查
 每次操作前，先確認：
 1. 目標系統是什麼
 2. 這次操作的目的為何
 3. 是否需要附件
 4. 是否已有文件編號
 5. 是否需要建立操作記錄
 ## 2. 系統判斷
 ### 線上公文
 適用於：公文建立、上傳、送簽、帶附件等流程
 ### EFLOW
 適用於：流程送件、附件上傳、流程狀態追蹤等
 ### FORMBUILD
 適用於：表單填寫、欄位輸入、附件上傳、資料提交等
 ## 3. 附件處理規則
 若系統需要附件：
 - 先取得文件編號
 - 依系統類型到指定資料夾找檔案
 - 驗證檔名是否符合規則
 - 驗證是否為最新版本
 - 驗證附件是否齊全
 ## 4. 操作輸出
 每次完成操作後，至少記錄：
 - 日期時間
 - 操作系統
 - 文件編號
 - 操作目的
 - 使用附件
 - 結果（成功 / 失敗 / 阻塞）
 - 下一步
 # Standard Response Format
 當使用此 skill 時，請依下列格式回應：
 1. 系統名稱
 2. 本次操作目的
 3. 需要的前置資料
 4. 執行步驟
 5. 附件檢查
 6. 完成後記錄
 7. 可能錯誤與處理方式
 # Subsystem Notes
 ## SP-OFFICIAL-DOC
 重點：公文流程、附件、送件狀態
 ## SP-EFLOW
 重點：流程節點、附件、送件前檢查
 ## SP-FORMBUILD
 重點：表單欄位、填寫規則、送出驗證
--- a/ProjectManager/skills/project-governance/SKILL.md
+++ b/ProjectManager/skills/project-governance/SKILL.md
@@ -1,98 +0,0 @@
 ---
 name: project-governance
 description: 用於判斷新工作應歸屬哪個主專案、子專案或共用規則，並維持專案、子專案、任務、規則四個層級的邊界清楚。
 ---
 # Purpose
 此 skill 用來避免將「類別、專案、子專案、任務」混淆。
 適用於以下情境：
 - 使用者提出新的工作、想法或需求
 - 需要判斷是否建立新專案或新子專案
 - 需要把任務正確掛到既有專案
 - 需要判斷某件事是共用規則，而不是專案內容
 # Core Rules
 ## 1. 四層模型
 1. 規則（Rules）
   - 共用命名規範
   - 文件編號規則
   - 附件歸檔規則
   - SOP 與記錄格式
 2. 主專案（Projects）
   - `P-ONLINE-DOC-AGENT`
   - `P-ETL-VISUAL-PLATFORM`
 3. 子專案（Subprojects）
   - 某主專案下的模組、工作流、系統分支
 4. 任務（Tasks）
   - 可執行、可完成、可驗收的最小工作單位
 ## 2. 分類判斷規則
 當收到新工作時，依序判斷：
 ### A. 這是共用規則嗎？
 若是關於以下內容，歸入 Rules：
 - 附件資料夾如何放
 - 文件怎麼編號
 - Agent 如何記錄工作
 - 線上操作 SOP 的共同格式
 ### B. 這是屬於哪個主專案？
 - 若與線上公文、EFLOW、FORMBUILD 的操作、自動化、附件、送件流程有關，歸入 `P-ONLINE-DOC-AGENT`
 - 若與 ETL、Stored Procedure、欄位 mapping、LLM 比對、資料轉換可視化頁面有關，歸入 `P-ETL-VISUAL-PLATFORM`
 ### C. 是否應建立子專案？
 符合以下任一條件時，建立子專案：
 - 有獨立系統或獨立頁面
 - 有獨立流程或 SOP
 - 有獨立輸入輸出或文件產出
 - 有明顯可拆分的技術模組
 ### D. 是否只是任務？
 若該工作可在單次工作期內完成，且有明確完成條件，則建立為任務，不建立子專案。
 # Required Output Format
 在分析新工作時，固定輸出：
 1. 歸屬層級：Rule / Project / Subproject / Task
 2. 所屬主專案
 3. 所屬子專案（若有）
 4. 建議任務名稱
 5. 下一步最小可執行動作
 6. 是否需要寫入工作記錄
 # Examples
 ## Example 1
 輸入：EFLOW 送件時要帶 PDF 附件，並確認檔名格式
 輸出：
 - 層級：Rule + Task
 - 主專案：P-ONLINE-DOC-AGENT
 - 子專案：SP-EFLOW / SP-ATTACHMENT-RULES
 - 任務：定義 EFLOW 附件命名與上傳前檢查規則
 - 下一步：建立 EFLOW 附件規則草稿 v1
 ## Example 2
 輸入：比較 Stored Procedure 輸出欄位與目標文件欄位差異
 輸出：
 - 層級：Subproject + Task
 - 主專案：P-ETL-VISUAL-PLATFORM
 - 子專案：SP-LLM-DIFF-CHECK
 - 任務：建立 SP 與目標文件欄位對照表 v1
 - 下一步：蒐集 SP 欄位清單與目標文件欄位清單
 # Response Style
 - 優先做歸類，再做執行建議
 - 不把技術類別直接當成主專案
 - 若工作本質是規則，必須明確指出它不是獨立主專案
--- a/skills/tts-voice/handler.ts
+++ b/skills/tts-voice/handler.ts
@@ -8,7 +8,7 @@
 *   - curl CLI
 */
-import { execSync } from 'child_process';
+import { execSync, spawnSync } from 'child_process';
 import { readFileSync, existsSync, unlinkSync } from 'fs';
 const LUXTTS_BASE = 'http://localhost:7860';
@@ -113,19 +113,28 @@ function generateSpeech(text: string, params: TtsParams): string | null {
  const outPath = `/tmp/tts_output_${timestamp}.wav`;
  try {
-    const httpCode = execSync(
+    const args = [
-      `curl -s -o ${outPath} -w "%{http_code}" ` +
+      '-s',
-      `-b ${COOKIE_JAR} ` +
+      '-o', outPath,
-      `-X POST ${LUXTTS_BASE}/luxtts/api/tts ` +
+      '-w', '%{http_code}',
-      `-F "ref_audio=@${REF_AUDIO}" ` +
+      '-b', COOKIE_JAR,
-      `-F "text=${text.replace(/"/g, '\\"')}" ` +
+      '-X', 'POST',
-      `-F "num_steps=${params.numSteps}" ` +
+      `${LUXTTS_BASE}/luxtts/api/tts`,
-      `-F "t_shift=${params.tShift}" ` +
+      '-F', `ref_audio=@${REF_AUDIO}`,
-      `-F "speed=${params.speed}"`,
+      '-F', `text=${text}`,
-      { timeout: 120000 }  // 2 min timeout for CPU synthesis
+      '-F', `num_steps=${params.numSteps}`,
-    ).toString().trim();
+      '-F', `t_shift=${params.tShift}`,
      '-F', `speed=${params.speed}`,
    ];
-    if (httpCode === '200' && existsSync(outPath)) {
+    const result = spawnSync('curl', args, {
      timeout: 120000, // 2 min timeout for CPU synthesis
      encoding: 'utf-8',
    });
    const httpCode = (result.stdout || '').trim();
    if (result.status === 0 && httpCode === '200' && existsSync(outPath)) {
      return outPath;
    }