標籤: 臺灣

  • 我的家庭照顧 14 個 HTML 工具:dementia-care monorepo + 實戰使用指南

    重點摘要

    • dementia-care monorepo 是 14 個 HTML/Python 工具的 personal toolkit:圍繞「家人照顧」這件事,自家用為主,朋友(藥師)+ 社區照護者也用得上。
    • 起源:照失智媽媽 2 年急速進展 + 育兒 2023 年出生女兒,前面有 15 年照爸爸 stroke 失能 secondary 經驗。每天遇到 friction 就寫一個小工具。
    • 上位 mission:「讓整個家忙起來」(ambient engagement,Marx & Cohen-Mansfield 2010 循證概念)—— 工具不是治療,是降低照護者啟動 friction。
    • 共用 spec:純前端、單檔 HTML、0 CDN、0 build、離線可用、繁體中文、大字大按鈕、SVG emoji favicon、GitHub Pages 部署。
    • 5 條自我約束(2026-04-28 後):凍結新 sub-project 60 天 / commit cap 20/天 / 每週一個下午全關 / 0 CDN 機器化守門 / 不主動推工具只分享方法。
    • 跨專案 lessons:純黑白對白內障是錯的 frame、圖書館 ≠ 景點 precision contract、Google Maps fallback default pin 陷阱、Selenium 驗證 self-use 例外、物件 literal 尾逗號讓整頁 blank。

    dementia-care monorepo 是 14 個圍繞家庭照顧的 HTML/Python 工具集,過去半年累積。為什麼會有這個 repo?照失智媽媽,順便做給太太、藥師朋友的太太、社區照護者用 ——「自家工具集 + 經驗分享」,不是 community product。

    這篇是這個 monorepo 的全面整理:14 個工具的分工、起源故事、共用設計原則、5 條自我約束、5 條跨專案踩坑 lessons。給想做類似 personal toolkit 的人參考,也給之後的我自己回頭看為什麼這樣設計。

    為什麼會有這個 monorepo?

    結構上設計給:白天只有你跟長輩、家屬 backup 0、商業 app 都假設你有時間引導。我家 timeline:

    • 15 年照父親 stroke 失能(secondary,媽媽是 primary,2024 過世)
    • 2024 起媽媽輕度失智 → 2 年急速進展到中重度
    • 2023 出生女兒進入 toddler 階段
    • 太太是藥師、有正職,白天無法 backup
    • 過去半年我變 primary caregiver

    每天遇到 friction(媽媽問同樣問題第 50 次 / 居服員交班沒交集 / 回診忘記想問什麼 / 女兒週末沒地方去) —— 直接寫一個小工具,不寫 spec、不開會、不等 backlog。半年累積 14 個。

    上位 mission 是「讓整個家忙起來」。對應的循證概念是 ambient engagement(Marx & Cohen-Mansfield 2010 “Engagement of Persons with Dementia”):環境引發的活動 vs 人引發的活動,失智長輩參與有意義活動的「量」與認知衰退斜率負相關。工具不是治療,是降低照護者啟動 friction —— 讓 engagement 在沒人陪伴的疲累照護日實際發生。

    14 個工具分四大類

    🧠 失智照護生態系(主線資料閉環)

    工具 類型 說明
    陪伴小幫手 v1 互動遊戲 15 個認知訓練遊戲,8 級難度滑桿自動選 10 個顯示
    陪伴小幫手 v2 試驗版 推薦式首頁 + 照護者陪伴指南 + 今日摘要分享
    白板 OCR Bot Telegram Bot 每日白板照 → Gemini 3 Flash(box-index 策略,磁鐵在第幾格)→ iDempiere Z_momSystem
    就診小幫手 Web App 回診前 prep:抓 iDempiere 異常、症狀分類、診間錄音

    👶 兒童 + 親子

    工具 類型 說明
    小朋友學習樂園 學齡前互動 1-6 歲 23 個活動,4 年齡層自適應深度
    週末出遊地圖 親子景點 全台 22 縣市 850+ 景點 + 多點路線規劃
    托嬰幼兒園手冊 方法論 0-6 歲托嬰中心 + 幼兒園選擇方法論(4 種類型對照,評估 SOP)

    📖 生活方法論手冊

    手冊 主題
    care-handbook 長照手冊:找居服員 / 日照 / 喘息 / 機構 / 看護工 / 失智專屬支援系統
    home-handbook 家中照護手冊:13 項物理改動 + 早午晚 SOP + 援手系統 awareness
    home-handbook-classic 家中照護手冊舊版(保留作對照,新版改用 home-handbook)
    garden-handbook 家庭園藝手冊(可食 + 觀葉 + 觀花 + 根莖類,陽台/窗邊/室內)— 對失智長輩是 behavior redirection 工具
    pet-handbook 家中寵物生活手冊(貓/狗/兔/鳥/魚/烏龜)—「會主動靠近的家人」,失智長輩 + 小孩雙受惠
    mindset 心法手冊 — 6 條視角(失智不是失能 / 用加法對抗減法 / 躁動不是無聊 / 動線是功能可及性 / 誠實版優於善意包裝 / 手冊是網狀不是清單)

    🧃 飲食 / 健康

    • health-drinks:**19 款醫療營養品 + 嬰幼兒配方 + 高蛋白補充品**並排比較(180-280ml 容量範圍。三重使用者:Tom 自家、藥師朋友、藥局客戶)

    失智照護主線:資料閉環長什麼樣?

    14 個工具裡 4 個是失智照護核心,串成一條 daily/weekly 閉環:

    [居服員 / 我]
        ↓ 拍白板照傳 Telegram
    whiteboard-ocr-bot
        ↓ Gemini 3 OCR + 人工 confirm
    iDempiere Z_momSystem(每天一筆紀錄)
        ↓ REST API
    mom-clinic-companion
        → 回診前產出「今天要問醫生的 3 件事」

    白板每天記錄媽媽 餐食 / 用藥 / 行為事件 / 睡眠時數。OCR Bot 把照片轉成結構化資料寫進 iDempiere(自家 ERP-as-PHR,Z_momSystem 表 12 欄位)。回診前 mom-clinic-companion 比對「上次回診 → 今天」vs「上上次回診 → 上次回診」兩個 window,抓變化顯著項目給神經科醫師看具體事件,不是「最近狀況不太好」這種模糊描述。

    這條主線運轉半年,媽媽每月回診從「我也不知道要說什麼」變成「上週三晚上她突然找不到回家的路」這種具體 evidence。神經科醫師根據具體事件調藥,比根據家屬情緒描述準確很多。

    共用設計原則 — 為什麼都是單檔 HTML?

    14 個工具共用同一套 spec:

    • 單檔 HTML:HTML + CSS + JS 全塞 `index.html`,不拆檔。對 backup / 修改 / 分享(直接寄一份)極友善。
    • 離線可用:所有資源 inline(SVG favicon、base64 圖、不依賴 CDN)。山區農場、長輩家 wifi 弱 都能跑。
    • 0 CDN 強制:禁止任何 fonts.googleapis / cdnjs / unpkg / jsdelivr / Google Analytics / 外部 script。原因:使用者打開網頁時瀏覽器會從使用者裝置直接發請求到 CDN 伺服器,洩漏 IP + User-Agent + 時間給第三方,違反 COPPA(兒童)/ GDPR-K / 個資法。有專屬 CI workflow `monorepo-cdn-ban.yml` 機器化守門(2026-04 加),違反即擋 push。**Caveat**:`health-drinks` 因為較早期建置仍用 Chart.js + Google Fonts CDN,是 monorepo 唯一例外,計畫之後遷移成 inline。
    • 0 build step:不進 npm、不進 webpack。寫完開瀏覽器看,改完 commit push 30-60 秒 GitHub Pages 部署。
    • 繁體中文 + 大字大按鈕:觸控友善,最小點擊區 48×48px。
    • SVG data URL emoji favicon:離線也有 tab icon。

    低視力對比:原本以為「純黑底 + 純白字 = 最大對比 = 最適合低視力長輩」,後來發現對中度白內障(monorepo 主場景)會因 forward light scatter 引發 halation/glare —— 21:1 是 over-shoot,不是越高越好。Evidence-based 替代:米白底深字(#222 on #f5f5f5)/ 深底淺字(#e8e8e8 on #1a1a1a)/ 字級 ≥ 24px / line-height ≥ 1.6。維持 WCAG AAA(7:1+)但消除極端 glare。

    5 條自我約束(2026-04-28 後加)

    跨 6 domain expert review 共識項。寫進 CLAUDE.md 變強制規則,我自己做時也守:

    1. 凍結新 sub-project 60 天(到 2026-06-30):14 個已過載,主軸佔比 < 35%。6 個月 450+ commits(`git log –since=’2025-11-01’`),「持續產出 = 情緒迴避」紅旗。例外:只允許 archive / 整併 / 刪除。解凍後若仍想開新工具,先在 blog 寫一篇「為什麼這值得開一個工具」,沒寫完不開。
    2. Commit cap 20 / 天 (soft warning):超過 20:pre-commit hook 跳對話框問「今天你媽吃幾餐、女兒抱了你幾次、你笑了幾次」。失智照護者 burnout 是 monorepo 結構性 SPOF —— Tom 倒下 = mom-clinic 朋友家屬可能誤診 = 整個生態系凍結
    3. 每週一個下午全關:不寫 code、不寫 blog、不規劃 feature。陪女兒、發呆、睡覺都行。「讓整個家忙起來」mission 不該包含 Tom 自己一刻不停。
    4. 0 CDN 機器化守門:`.github/workflows/monorepo-cdn-ban.yml` 自動掃所有 *.html。違反即擋 push。不再靠人記得。
    5. 不主動推工具,只分享方法:工具是 personal toolkit,維護優先順序看當下需要。不主動推給陌生使用者(避免讓人對「會被維護」產生錯誤期待)。朋友(藥師)是「資訊交流」不是「使用者」,不發配工具帳號。方法寫成 blog,blog 才是擴散渠道(這篇就是)。

    5 條跨專案踩坑 lessons

    1. 純黑白對白內障是錯的 frame

    「最大對比 = 最適合低視力」是錯的。對白內障(monorepo 主場景)forward light scatter 引發 glare,21:1 反而降可讀性。WCAG 21:1 是 物理可量化(luminance ratio),「適合低視力」是 臨床效果(可讀 + 不疲勞 + 不誘發 glare),兩者不是同一件事。Evidence-based:米白底深字 / 深底淺字 / 字級 24px+ / line-height 1.6。

    2. 圖書館 ≠ 景點:precision contract

    不同 place category 對 precision 容忍度不同。景點(公園 / 山林 / 老街)area centroid 1-2 km 噪音 OK(本身就大);圖書館 = 單一建築,1 km 偏差 = 不同樓棟 = 錯,不能套同一條 fallback 規則。對「single building」類,寧可 entry 數量少(精確) 也不要 area centroid(誤導 user)。

    3. Google Maps fallback default pin 陷阱

    Google Maps geocoding 找不到地址時不會回 error,而是 silent fallback 回最後一個成功 query 的 cached coord。kids-weekend 跑 23 筆 Playwright 有 3 筆全部 fallback 到同一個 [24.9790, 121.4579]。必跑 sanity gate:縣市 bounding box 比對。任何 geocoding pipeline 必須有 downstream sanity check —— 不能信「200 OK + 有 @lat,lng」就當作對的。

    4. Selenium 驗證 self-use 例外 ≠ photo scraping hard violation

    Google Maps Platform ToS 是合約不是法律,enforcement profile 對「自用 / 非商業 / 中等規模」幾乎為零。判斷不是 binary —— 看(1) self-use vs 商業化 (2) 一次性 vs 持續性 (3) 文字 vs 照片 三維度。kids-weekend 圖書館 geocode 落在「self-use + 一次性 + 文字座標」三個都 OK 的格子,屬技術性 ToS issue。但 photo extraction + redistribute 仍是 hard violation(著作權法 §91 §92),商業化應升級付費 API。

    5. 物件 literal 尾逗號讓整頁 blank

    2026-04-21 kids-companion 整頁 blank 事故:新增 IMG 物件忘記前一筆尾逗號,SyntaxError 整頁掛。單檔 HTML 沒 webpack 兜住,JS 一錯整頁 die。寫 lint script (`scripts/lint_places.py`)機器化檢查每筆 entry 結尾。

    為什麼不對外推銷?

    因為這是 tier 2 personal toolkit 不是 community product。三個原因:

    1. 維護順序看自家當下需要:某天我家 schedule 變、媽媽病程變、女兒入學,工具優先順序就變。對外推銷會建立「會被維護」期待,實際上我可能突然停某個工具 —— 對 user 不公平。
    2. SPOF 問題:14 個工具只有我一個 maintainer,我倒下整個 stop。對外推 = 對外承諾,承諾兌現不了 = 信譽損傷。
    3. 方法 vs 工具:方法可以用文字傳承,擴散性高;工具 binding 在我家 schedule + 我家硬體 + 我家數據格式。方法寫成 blog,工具留給有能力 fork 改的人。

    朋友(藥師)是「資訊交流者」不是「使用者」 —— 我跟她討論失智用藥,她跟我討論病人家屬,但我不發給她工具帳號讓她依賴我的伺服器。她想用就 fork,改成她家用。

    給想做類似 personal toolkit 的人的建議

    1. 明確 scope = self-use:這個 frame 鎖死所有設計決定 —— 不做 user account、不做 paywall、不對外推銷、不收 review。Scope 一變,所有 compliance / privacy / 合規 trade-off 全變。
    2. 單檔 HTML 是 personal toolkit 的甜蜜點:0 build / 0 server / 直接寄一份檔案 / 純前端 / 離線 / GitHub Pages 免費部署。技術簡單到不會卡住做事的人。
    3. 0 CDN 是隱私底線:任何外部 fonts / analytics 都洩漏 user IP。家庭應用(兒童 / 醫療 / 失智)不能讓 Google 知道你家在訪問什麼工具。寫 CI workflow 機器化守門,不靠人記得。
    4. 每個工具對應一個 friction:不要先想「我要做什麼工具」,要想「我每天卡在什麼」。卡在交班 → OCR Bot;卡在回診 → mom-clinic;卡在週末 → kids-weekend。
    5. 政府開放資料 > 商業 API scraping:libstat / data.gov.tw / TGOS 對台灣應用是乾淨 source,合規且持久。每個 domain 找對應的政府 source(圖書館 / 醫院 / 學校 / 古蹟)。
    6. self-use 工具不是免責令:Photo extraction、持續性 production scraping、商業化 仍是 hard violation。判斷 framework 看 (1) self-use vs 商業 (2) 一次性 vs 持續性 (3) 文字 vs 照片 三維度。
    7. 給自己自我約束:照護者 burnout 是結構性 SPOF。commit cap、每週全關一下午、凍結新 sub-project,這些不是「強制症」是「對抗持續產出 = 情緒迴避」的 hard rule。

    —— 工具實戰判斷與用法 ——

    三層分工:Handbook、工具、專業

    使用 monorepo 之前,先建立三層分工的觀念:

    作用 對應 monorepo 頻率
    Handbook 認識系統、申請流程、SOP 學習 care-handbook / home-handbook / childcare-handbook 階段性(剛確診、要申請居服員)
    工具 每日操作、降低啟動 friction 陪伴小幫手 / OCR Bot / mom-clinic / kids-weekend 每日 / 每週
    專業 診斷、用藥、急救、法律 神經科 / 精神科 / 1966 / 1925 / 119 / 共照中心個管師 回診 + 突發事件

    實戰原則:剛確診先讀 handbook(2-3 天密集吸收),3 個月後 handbook 慢慢變參考書,工具變每日操作,專業在事件發生時 escalate。

    7 個照顧場景對應工具速查

    場景 主要工具 配合 handbook
    失智剛確診那週 無工具(handbook 為主) home-handbook P0 + care-handbook 申請流程
    居服員每天交班 白板 OCR Bot home-handbook 居家日 SOP
    媽媽情緒不好想做點事 陪伴小幫手 v2(推薦)/ v1(自選)
    回診前一晚 mom-clinic-companion
    週末帶孩子去哪 kids-weekend(住哪 → 路線)
    孩子在家想做活動 kids-companion(2-6 歲 4 年齡層自適應) — (kids-companion 自己分齡)
    第一次申請長照 無工具(handbook 為主) care-handbook 7 步 SOP + 援手系統

    場景 1:失智剛確診那週 — handbook 為主

    剛確診那週不要急著上工具。先做 5 件事(home-handbook P0 章節):

    1. 法律 P0:輔助宣告 / 監護宣告 / 預立醫療決定 — 趁失智長輩仍有意思能力時辦,過了會難辦
    2. 醫療 P0:確認確診醫院 + 預約共照中心 + 申請重大傷病卡
    3. 防走失:愛心手鍊 / GPS / 鄰里通報網
    4. 物理改動 13 項(home-handbook 列清單):防滑地墊 / 衛浴扶手 / 廚房瓦斯總開關 / 大門感應…
    5. 申請長照:1966 → 照管專員到府評估 → 失能等級 → 服務媒合(care-handbook 7 步 SOP)

    這週不要碰工具。一邊吸收 handbook,一邊處理法律醫療 P0,一邊跟家人討論分工。工具是後面 2-3 個月開始有居服員 / 日照排班後才會用得上。

    場景 2:居服員每天交班 — 白板 OCR Bot

    白板 OCR Bot 解決交班斷層:居服員早上來、下午走;家屬晚上接手 — 中間 8 小時居服員紀錄不傳給家屬,神經科回診也說不清楚。

    實際流程:

    1. 家裡放一塊白板,居服員每天用筆寫紀錄(餐食 / 用藥 / 行為事件 / 睡眠)+ 用磁鐵標記固定欄位的選項
    2. 居服員下班前 / 我經過時拍照傳 Telegram bot(`telegram_bot.py`)
    3. Bot 走 `ocr_pipeline.py` → Gemini 3 Flash Preview API,**用 box-index 策略**(磁鐵在第幾格)避開手寫中文字元 OCR — human-as-verifier 設計
    4. 手機收到 bot push 訊息「請確認」,3 秒過目即可。錯了直接改文字回傳
    5. 自動寫入 iDempiere Z_momSystem(每天一筆 row,12 個欄位)
    6. 家屬晚上看 iDempiere 知道白天發生什麼,銜接夜間照護

    另也支援 📝 文字訊息 → 加時間戳(早 / 晚 / 大夜班)append 到當天備註欄;`/status` `/today` 指令查當天/累積狀態。`whiteboard-ocr-bot/index.html` 是純前端 demo 版本(模擬對話流程,不連網不傳資料),正式版要 Python + iDempiere REST API 跑在自家 server。

    關鍵 design:box-index 策略 + human-as-verifier 不是全自動。Gemini OCR 對手寫長輩字跡不一定 100%(尤其用藥名稱),所以白板用固定欄位 + 磁鐵 — Gemini 只要識別「第幾格有磁鐵」這種離散 boolean,不用識別自由手寫,大幅降低錯誤率。

    場景 3:媽媽情緒不好想做點事 — 陪伴小幫手 v2

    陪伴小幫手有 v1 / v2 兩版本並存:

    情境 用 v1 還是 v2?
    媽媽心情好,自己想挑 v1(10 格遊戲卡讓她挑)
    媽媽疲累 / 不擅選擇 / 照護者也累 v2(一鍵推薦「今天一起做這個好嗎」)
    想知道對長輩說什麼話帶遊戲 v2(每遊戲 3 條陪伴指南)
    想記錄今天玩了什麼貼 LINE 給家人 v2(每日摘要一鍵複製)

    v2 推薦邏輯:依時段(早 / 午 / 晚 / 深夜)+ 最近玩過避免重複 + 當前難度自動挑一個遊戲。次要選項「換一個 / 我想自己選」字級縮小、無底色,降低照護者選擇癱瘓 — 是給疲累照護者的設計。

    難度滑桿 1-8 對應方式(`v1 CLAUDE.md` 規格):

    • 1-2 輕度:遊戲篩選後較難(辨識變化小、選項多),語音只朗讀題目
    • 3-6 中度:遊戲難度中等,語音朗讀題目 + hover 選項唸出
    • 7-8 重度:遊戲篩選後最簡單(選項少、對比大),語音朗讀題目 + 所有選項,重複一次

    遊戲庫(`GAME_LIBRARY`)15 個遊戲每個有 `min`/`max` 範圍,`selectGames(level)` 從符合範圍的遊戲中隨機抽 10 個顯示首頁。選擇難度時看當週實際狀況試,不是越難越好 — 失智長輩做不到會挫折,做太簡單會無聊

    場景 4:回診前一晚 — mom-clinic-companion

    失智回診最大的問題是「**最近狀況不太好**」這種家屬模糊描述,神經科沒辦法調藥。mom-clinic-companion 讀 iDempiere `Z_momSystem` 表(白板 OCR Bot 寫入的),把 raw data 歸納成照護者可以記住、可以問的內容。

    實際 4 個 sections(`mom-clinic-companion/index.html` H2):

    1. 🚨 值得跟醫生討論的 — 規則引擎自動比對「上次回診 → 今天」vs「上上次回診 → 上次回診」兩個 window,找變化顯著項目
    2. 💭 這一個月媽媽發生過 — 從白板 OCR Description 欄抓症狀關鍵字
    3. 📋 這次要問醫生 — 從上面兩區一鍵「加進問題」,手動補其他
    4. 🎙️ 診間錄音 — 醫師講話 STT 轉字,回家同步回 iDempiere

    核心設計是回診日期感知:`APP.visits` 是回診日期 array,`computeWindows()` 產生最新兩段比對區間 — 因為實際回診頻率不規則(通常每月,有時兩週),按日曆切會不準。

    場景 5:週末帶孩子去哪 — kids-weekend(MAP 工具)

    kids-weekend 是 monorepo 裡最大的 MAP 工具:全台 22 縣市 851 筆親子景點 + 路線規劃(`STATE_VERSION` 3,單檔 HTML ~700KB)。解決的具體問題是「從家出發 X 公里範圍內,有什麼順路可以串成一日」 —— 媽媽社團、IG 收藏、Google Maps 我的清單,都做不到「按距離 + 順路 + 一鍵多點導航」這件事。

    1 題 wizard 是 deliberate 砍簡 — 從 4 題到 1 題

    2026-04 砍簡前,wizard 有 4 題:住哪 + 天氣 + 年齡 + 範圍。實測發現 user(太太、藥師朋友)80% 都直接 next 跳過後 3 題:

    • 天氣晴雨:家長自己抬頭看,問了多餘
    • 年齡:每筆景點 entry 已有 `ages: [‘0-2′,’2-3′,’3-6’]` 標籤,filter UI 之後再勾就好
    • 範圍:**家庭多在 20 km 內**(自家 + 朋友家實測 4 個月),預設 20 km 一拉就動

    所以剩 1 題:**「住哪?」**(GPS 一鍵 / 縣市 + 區下拉)。設完直接看推薦清單,範圍可拉滑桿改 5-400 km。砍題目比加 feature 更重要 —— personal toolkit 的設計訓練。

    實際 6 步使用流程

    1. 設家 — 第一次選,之後 `localStorage[kidsWeekendState]` 記住。GPS 一鍵會 reverse geocode 成「📍 新北土城」(不顯示醜的經緯度)
    2. 看推薦清單 — 預設 20 km 內景點,室內/戶外/觀光工廠/博物館/公園/海邊/廟宇/老街全混合
    3. 篩 filter — 晴天/雨天/0-2 歲/室內/避開人多/避開假日塞車黑名單
    4. 勾比較籃 — 1-3 個目的地加入比較籃
    5. 看路線預覽 — corridor 演算法找順路景點(預設 5 km corridor,`STATE.preferences.corridorWidthKm`)+ 計算多點總公里 + 拖 ⋮⋮ 換站順序
    6. 一鍵 Google Maps 多段導航 — 直接丟 Maps app(`maps.google.com/dir/?…` URL),不用手動複製貼

    實例(README 範例):「搜尋觀音山設目的地 → IKEA 新莊距路線 0.44 km ➕ 加入 → 五股 ➕ 加入 → 想加林口三井但 5.13 km 擦邊 → corridor 拉到 6 km → 拖 ⋮⋮ 把林口移到第 1 站 → 一鍵 Google Maps」。

    Place precision contract:景點 vs 圖書館 fallback 策略

    kids-weekend 的距離計算 priority(`getPlaceCoords()` line 2354):

    1. 先查 `PRECISE_COORDS[place.id]` — 有就用
    2. 沒有 → fallback `getCoordsFromArea(place.area)` 取「縣市 + 區」中心點(`TAIWAN_DISTRICTS` lookup,286 個區 centroid)
    3. 都沒有 → null,distance filter 排除

    但圖書館不能 fallback 區中心(本文上方「跨專案 lesson 2」)。圖書館是單一建築,1 km 偏差 = 不同樓棟 = 錯。所以 2026-04-30 圖書館 wave A→C 擴點時,**沒有精確 coord 的圖書館直接 drop,不入庫**(reject 連江縣文化處 / 桃園兒童文學館 / 高雄新興閱覽室 3 筆,因為 Google Maps fallback 到 default pin)。

    Metadata flag 系統 — 怕感冒 / 怕塞 / 失智注意

    每筆景點除了基本欄位(name / area / ages / types / hours / website),還帶 metadata flag 給推薦邏輯參考:

    Flag 含意 影響
    `elder_friendly: true` 長輩友善(平緩、無障礙、有座位) 失智 + 親子混合家庭優先推薦
    `weekend_jam: true` 假日塞車黑名單(陽明山 / 九份 / 淡水) 勾「避開塞車」會排除
    `dementia_caution: true` 失智長輩慎入(動物園 / 大型賣場 / 高 crowd 易迷路) 混合家庭手動觀察
    `crowd: ‘low|mid|high’` 人潮 enum UI「🤧 避開人多景點」剔除 high

    851 筆景點怎麼累積 — 5 wave + 圖書館 wave A→C

    景點不是一次抓進來的,分 wave 增量。每 wave 對應「家附近還缺什麼類型」的 surface gap:

    Wave 主題 +景點
    v3.11 base 親子館 / 公園 / 觀光工廠 主軸 ~770
    v3.12 0-2 歲友善 補嬰幼兒場域(托嬰中心 / 兒童美術館) +8
    v3.13 觀光工廠 DIY 體驗 + 雨天首選 +12
    v3.14 露營區 Glamping + 渡假農場 +10
    v3.15 雲嘉南高屏 南台灣覆蓋補齊 +14
    圖書館 wave A→C(2026-04-30) 縣市總館 + 親子閱覽室 + 文學/繪本 +33

    圖書館 wave 走獨立 pipeline:libstat 國家圖書館抓政府公開資料 → OSM Overpass strict verify(`amenity=library` POI 全台 853 個)→ Google Maps Selenium geocode 補不足 → 縣市 bbox sanity 過濾 → 通過才入庫。三條 source 各補不同覆蓋率,合規(政府開放資料 0 ToS)+ 精確(building-level coord)。

    每個 wave 的關鍵 lesson:**對應實際 user gap,不盲目擴量**。盲目擴點會稀釋信號(user 搜「週末去哪」跳出一堆樓上閱覽室,反而難用)。圖書館 wave 砍 46 筆閱覽室因為「樓上小空間 ≠ destination」,只進 33 筆 high-value。

    場景 6:孩子在家想做活動 — kids-companion

    kids-companion 是 2-6 歲兒童平板學習 app,核心設計是「自適應深度 (Adaptive Depth)」 —— 同一內容,不同年齡,不同深度。4 個年齡層各有版本:

    • toddler(幼幼班 1-2 歲):選項 2、語音題目+選項重複、目標字 140px、無拖拉
    • small(小班 3-4 歲):選項 2-3、語音題目+選項、目標字 120px
    • middle(中班 4-5 歲):選項 3-4、語音題目+hover、目標字 100px、可拖拉
    • large(大班 5-6 歲):選項 4-6、只朗讀題目、目標字 80px

    使用流程:設角色 emoji + 年齡層(toddler/small/middle/large) → 首頁活動卡 → 系統依年齡層自動調選項數 / 字級 / 互動方式。設計哲學在 brain memory `project_kids_companion_philosophy.md`。

    跟陪伴小幫手 v1/v2 關鍵差異:Web Speech API pitch 設定不同。kids-companion `pitch: 1.2`(高頻活潑感吸引兒童);陪伴小幫手 v1/v2 都已校正成 `pitch: 0.95`(老年聽力 presbycusis 高頻損失,低頻反而清楚)。同 API 不同設定,因為使用者生理不一樣。

    場景 7:第一次申請長照 — care-handbook 7 步 SOP

    長照申請新手最大的痛點:不知道要打給誰、要準備什麼、評估會問什麼。care-handbook 直接給 7 步 SOP:

    1. 打 1966(長照專線,免費)→ 報長輩姓名 + 縣市 + 失智症
    2. 等照管專員到府評估(通常 1-2 週內)
    3. 準備評估會問的:長輩 ADL/IADL 量表自評 + 失智診斷書 + 重大傷病卡(如有)
    4. 失能等級判定(2-8 級)→ 對應給付額度
    5. 服務媒合(居服員 / 日照 / 喘息)→ 排面試
    6. 居服員 / 日照面試 SOP:重點問題、紅旗信號、簽約注意事項(handbook 列詳細 checklist)
    7. 失智專屬支援:申請共照中心 + GA07 家屬訓練諮商給付碼 + 巷弄失智據點(這條在 care-handbook 獨立章節,大多家屬不知道)

    handbook 不取代 1966,是讓你打 1966 之前知道要問什麼。直接打 1966 也可以,但你會發現照管專員講的有些聽不懂(BA / CA / GA01-07 給付碼),先看 handbook 心裡有底再打。

    場景 8:選托嬰中心 / 幼兒園 — childcare-handbook

    childcare-handbook 是托嬰中心 + 幼兒園選擇方法論手冊(0-6 歲),不是「找最便宜」「找最近」這種比價工具,而是教**怎麼系統性評估** —— 在報名截止前知道「該看哪些點、該準備哪些東西、該追蹤哪些時間」。

    4 種托育類型(0-2 / 2-6 歲分流)

    • 托嬰(0-2 歲)3 類型:公托 / 準公共 / 私立
    • 幼兒園(2-6 歲)4 類型:公幼 / 非營利 / 準公共 / 私立

    5W1H 評估方法論(Who / What / When / Where / Why / How)

    Handbook H1「🎯 5W1H 評估方法論」拆 5 個 H2:你家是誰 / 選哪一類 / 什麼時候動 / 距離與動線 / 決策框架。每個維度有具體 checklist。

    核心 family mode:`sandwich`(三明治世代) — 全域狀態 `STATE.familyMode` 有 4 個值:`normal` / `sandwich`(同時照顧失智長輩 + 幼兒)/ `dual_income` / `single_parent`。**Tom 家是 sandwich**,工具設計 deliberately 給三明治世代設想:選離長輩家近 vs 離公司近的 trade-off、晚接送對失智長輩晚餐 SOP 的影響、公幼接送時間跟長輩日照時間怎麼對齊。

    state(`localStorage[childcareHandbookState]`):`childAge` enum + `familyMode` enum + `favorites` 收藏園所類型 + `checklist` 文件 / 行動完成度。可匯出匯入 JSON。

    場景 9:陽台種菜 / 觀葉 / 觀花 — garden-handbook

    garden-handbook 是家庭可食 + 觀葉 + 觀花 + 根莖類種植手冊,涵蓋陽台、窗邊、室內盆栽。每個 plant 一個 entry,**統一 10-section 結構 + 5W1H 總覽 + 購物籃匯入**。

    為什麼 garden 在失智照護 monorepo 裡?

    因為 repo 上位 mission「讓整個家忙起來」(ambient engagement)—— 用植物讓家裡有生長中的東西、每天互動的動作、可採可賞的成果。對失智長輩,種植是 behavior redirection 的有效工具:她躁動時遞她澆水器,「來,我們去澆花」是個比「坐下休息」更不抗拒的指令,因為她可以「做有意義的事」。

    10-section 結構 + 5W1H + 規劃模式

    每個 plant entry 統一格式:

    • 5W1H 5 秒總覽:`renderPlantOverview()` 從 meta + sections 自動抽 6 行摘要(怎麼種 / 多久收成 / 適合哪些家)
    • 10-section 結構:選盆 / 選土 / 種法 / 澆水 / 採光 / 病蟲害 / 採收 / 留種 / 失敗訊號 / 跟其他植物搭配 — 每株都這 10 段
    • 規劃模式:設定頁 toggle 開啟,filter 按「家庭模式 / 季節 / 採光」推薦對應 plant
    • 購物籃匯入:一鍵把該 plant 需要的盆/土/工具加入購物清單(連到 brain memory `feedback_starter_kit_ordering.md`「基礎設施先,活體後」原則)

    state:`localStorage[gardenHandbookState]` — 最愛 / 購物籃 / 規劃模式 / 照護級數 / memos,可匯出匯入 JSON。

    場景 10:讓家有「會主動靠近的成員」 — pet-handbook

    pet-handbook 是家中寵物生活手冊,按 6 個物種分類:**貓 / 狗 / 兔 / 鳥 / 魚 / 烏龜**。每物種下有多個 topics(親訓 / 飼料 / 醫療 / 訓練)。

    跟 garden 的 frame 區別 — 寵物是會主動靠近的家人

    核心定位:寵物是會主動靠近你的家人。跟植物不一樣 —— 他會自己跳上你腿、用頭頂你手、發出呼嚕聲。他不是被動被照顧的對象,**是家庭成員**。

    對失智長輩尤其重要 —— 當她大腦退化、溝通困難,一個會自己靠近的生命,是「她還被需要、她還存在」的證明。garden 是 ambient(植物在那裡),pet 是 active(寵物來找你)—— 兩者並用補不同層次的 family vitality。

    對小孩:寵物從小同住的孩子發展(empathy / 責任感 / motor skills)有 evidence-based 好處。混合家庭(失智長輩 + 幼兒 + 寵物)是 monorepo 主場景之一。

    場景 11:照護判斷迷茫時 — mindset(6 條視角)

    mindset 是「心法手冊」 — 不是 SOP、不是 checklist,是一位失智照護者面對新狀況時,腦袋裡跑的判斷視角。中英雙語(zh + en),開源歡迎其他家屬補充。

    6 條視角

    • 視角 1:失智不是失能 — 她不是壞了,是用不一樣的方式運轉
    • 視角 2:用加法對抗減法 — 認知衰退是減法,加新刺激抵銷
    • 視角 3:躁動不是無聊 — 行為背後通常有具體 trigger(尿急、肚子餓、燈太亮)
    • 視角 4:動線是功能可及性 — 她做不到不一定是失能,可能是動線設計
    • 視角 5:誠實版優於善意包裝 — 不要編故事騙她,她感受得到
    • 視角 6:手冊是網狀不是清單 — 沒有「按順序做完」這種事

    caveat 自註:Handbook 自己寫了「⚠️ 不要把任何視角當絕對」 —— 「這 6 條視角是我寫家中照護手冊時用的判斷方式,不是失智照護的真理」。比如「視角 2 加法對抗減法」跟主流的「懷舊治療(Reminiscence Therapy)」(用過去記憶喚起情感連結)有衝突。Tom 在文章明文承認這個衝突。

    這個工具不解決具體問題,而是在其他工具給不了答案時,**回頭問:我用什麼 frame 在想這件事?** Handbook 是網狀的,在失智路上某些時刻會用上。

    場景 12:長輩 / 病人 / 嬰兒選營養品 — health-drinks

    health-drinks 是19 款醫療營養品 + 嬰幼兒配方 + 高蛋白補充品的並排比較工具(180-280ml 容量範圍)。**不是市售飲料**,是給病人 / 長輩 / 嬰兒喝的營養補充品(葡勝納 / 完膳 / 安素 / S-26 / 倍速益 / 康健等)。

    三重使用者

    • Tom 自家 — 失智媽媽吞嚥退化階段選低糖高蛋白配方
    • 藥師朋友 — 跟客戶解釋「葡勝納原味跟菁選香草」差別時要快速比成分
    • 藥局客戶 — 拿出手機看比較表自己挑(藥師沒空講)

    資料流:拍包裝 → AI 擷取 → 手填 drinks.js

    每加新飲品的流程:

    1. 藥局買回來拍包裝側標籤
    2. AI(Gemini / Claude)從圖片擷取營養成分
    3. **手填**到 `data/drinks.js`(brain memory `health-drinks-data-entry.md` 「拍標籤說『加進去』就全填,包含微量元素,不可自行省略」原則 — `feedback_nutrition_label_fulldata.md` lesson)
    4. UI 並排比熱量 / 糖 / 鈉 / 蛋白質 / 脂肪 / 維生素 / 礦物質

    monorepo 唯一 CDN 例外:health-drinks 較早建置仍用 Chart.js + Google Fonts CDN(Noto Sans TC)。圖表呈現用 Chart.js 4,字體用 Noto Sans TC。違反 monorepo 0 CDN 強制規定 —— 計畫之後遷移成 inline,但目前留著作為「歷史包袱」example。新工具不准走這條路。

    何時不該用工具,直接找專業

    工具看到「預期外的 pattern」就停用,改找專業。具體訊號:

    訊號 該找誰 為什麼
    突然拒食 ≥ 3 天 神經科 / 急診 可能是 UTI / 吞嚥退化 / 譫妄,不是「沒胃口」
    行為驟變 24 小時內 急診先排除 UTI 中老年 UTI 常表現為譫妄不是發燒
    跌倒 119 / 急診 頭部撞擊、髖關節骨折看似輕微會延遲爆發
    照顧者撐不住 1925 安心專線 / 共照中心個管師 Burnout / 預期性悲傷有專業 evidence-based 支援
    小孩發燒 ≥ 39°C 連 2 天 兒科 / 急診 tools 不會幫你看川崎 / 流感 / 腸病毒

    原則:工具是 baseline 操作,異常事件外溢就 escalate。不要用「我家工具上看了沒問題」當不去看醫生的理由。

    工具互鎖:資料閉環怎麼運作

    14 個工具裡不是每個都獨立。失智照護核心 4 個工具串成 daily/weekly 閉環:

    每天:
    [居服員 / 我] 寫白板 → 拍照傳 Telegram
        ↓
    [白板 OCR Bot] Gemini OCR + confirm
        ↓
    [iDempiere Z_momSystem] 每天一筆紀錄
    
    每月:
    [mom-clinic-companion] 拉一個月紀錄
        ↓
    產出回診清單 → 神經科看具體 evidence
        ↓
    醫師調藥決定寫回 iDempiere
    
    每月共照中心月聚:
    [care-handbook 援手系統] 個管師有資料看可以諮詢
        ↓
    社工 / 物理治療 介入決定

    關鍵設計:資料只進 iDempiere 一次,各工具讀同一個 source。不是 OCR Bot 一個資料庫、mom-clinic 另一個資料庫 — 那會分裂。所有寫入收斂到 iDempiere,所有讀取從 iDempiere 出來。

    iDempiere 是台灣 open source ERP,我把它當 PHR (Personal Health Record) 用。對家庭規模 overkill,但有 Z_table 自訂 + REST API + audit log 的 enterprise 級資料管理,這條主線運轉半年沒掉資料。

    不是處方,是 invitation

    這套工具不是處方。每家狀況不同 — 有的家有外籍看護工、有的家三代同堂家屬 backup 充足、有的家在偏鄉服務不完整。我家是「白天 solo + 配偶藥師有正職 + 兒女幼小 + 父母 secondary 經驗 15 年」這個極窄 niche,所以工具 design 偏向「降低 solo 啟動 friction」。

    如果你家狀況跟我接近,這套工具開箱可用;不接近,把它當「一個照護者怎麼設計自家工具」的 reference,fork 改成你家用的。原始碼在 GitHub,部署在 tm731531.github.io/dementia-care

    有相關問題歡迎在 blog 留言 — 工具不主動推,但方法 / 經驗 / 踩過的坑歡迎交流。

  • iDempiere Plugin 開發完整指南:踩遍台灣統一發票的 10 個坑

    重點摘要

    • 我們用兩天為 iDempiere 12.0 從零開發了台灣統一發票 OSGi Plugin,踩了至少 7 個主要的坑
    • 最燒時間的 bug:SeqNoGrid 缺失導致 Grid View 在按「新增」時拋出 IndexOutOfBoundsException——官方文件完全沒提
    • EventHandler 模式是 iDempiere 12 的正確驗證方式,ModelValidator 不透過 OSGi DS 登錄根本不執行
    • 2Pack ZIP 結構、事件主題比較、雙 JVM 部署問題——每一個都能讓你白白浪費半天

    這篇文章記錄了我們為 iDempiere 12.0 從零開發台灣統一發票(統一發票)與營業稅申報 Plugin 的完整過程。如果你正在開發 iDempiere Plugin,這篇文章能幫你少掉至少一天的除錯時間。

    為什麼要做這個 Plugin?

    台灣的統一發票制度獨特而嚴格:每兩個月一期的雙月申報週期、財政部核配的字軌號碼(如 AA01234567)、三聯式(B2B)和二聯式(B2C)的不同計稅方式、以及嚴格的 FLOOR 取捨規定。

    這些都是 iDempiere 標準功能完全沒有覆蓋的。既有的 C_Invoice 系統不知道什麼是「字軌」,不知道進項折讓要在哪一期申報,更不知道 401 申報表長什麼樣子。所以我們做了這個 Plugin。

    系統架構概覽:四張表對應四個階段

    iDempiere Plugin 開發的核心是理清業務模型。台灣統一發票有清楚的生命週期,我們用四張資料表對應:

    財政部核配字軌
          │
          ▼
    TW_InvoicePrefix      ← 字軌管理(AA、AB 等,號碼範圍、有效期)
          │ 開立發票時
          ▼
    TW_Invoice_Prefix_Map ← 每張發票的字軌號碼對應(含買方統一編號)
          │ 如有退貨/折讓
          ▼
    TW_InvoiceAdjustment  ← 銷項/進項折讓(方向、期別、超期申報)
          │ 期末
          ▼
    TW_TaxStatement       ← 401 申報表(銷項稅、進項稅、留抵、應納稅額)

    技術層面:OSGi bundle(Equinox),2Pack 管理 dictionary,AbstractEventHandler 做 PO 事件驗證,服務層純 Java 方便單元測試。最終成品:87 個測試全部通過,4 張 TW_* 資料表,4 個 iDempiere 視窗。

    把台灣稅法翻成 Java 程式碼

    稅額計算:FLOOR,不是 ROUND

    這是財政部的明確規定,一律捨去,不四捨五入。聽起來簡單,但在邊界值差一塊錢,申報出去就是對不上帳:

    // 二聯式(B2C):含稅金額已知,反推銷售額和稅額
    BigDecimal saleAmount = grossAmount
        .divide(new BigDecimal("1.05"), 0, RoundingMode.FLOOR);
    BigDecimal taxAmount = saleAmount
        .multiply(new BigDecimal("0.05"))
        .setScale(0, RoundingMode.FLOOR);
    
    // 注意:taxAmount ≠ grossAmount - saleAmount
    // 財政部規定:用前者(先算銷售額,再乘 5%)

    字軌狀態機:單向前進

    字軌狀態只能往前走,不能回頭:I(未啟用)→ A(使用中)→ C(已用完)。這是台灣稅法要求,已啟用的字軌必須被追蹤,不能撤回。

    // EventHandler 在 PO_BEFORE_CHANGE 攔截
    if ("A".equals(oldStatus) && "I".equals(newStatus))
        throw new AdempiereException("使用中字軌不可降回未啟用(台灣稅法)");
    if ("C".equals(oldStatus))
        throw new AdempiereException("已用完字軌不可再變更狀態");

    雙月申報期別計算

    // 從發票月份算期別
    int period = (month - 1) / 2 + 1;  // 1=1-2月, 2=3-4月 ... 6=11-12月

    七個真實踩坑紀錄

    坑 1:事件主題比較,一個字毀掉一切

    這個 bug 讓狀態驗證完全靜默失效了很久。症狀是:程式碼看起來完全正確,但驗證從來不觸發。

    // 錯誤 — 永遠不會觸發
    if (topic.endsWith("po_before_change")) { ... }
    
    // 正確
    if (IEventTopics.PO_BEFORE_CHANGE.equals(topic)) { ... }

    iDempiere 的 topic 格式是 org/adempiere/po/PO_BEFORE_CHANGE(全大寫),endsWith 配對小寫後綴當然不匹配。靜默失效最可怕——不報錯,只是所有驗證都沒執行。規則:事件主題永遠用 IEventTopics 常數。

    坑 2:ModelValidator 是個陷阱

    Validator 類別一開始實作了完整的 ModelValidator 介面(initialize、modelChange、docValidate、login…),程式碼寫得很整齊,但驗證從來不執行。

    原因:ModelValidator 需要透過 ModelValidationEngine.addModelValidator() 主動登錄。單純 implements ModelValidator + @Component 什麼都不會發生。

    正確的 iDempiere 12 Plugin 驗證模式:

    // *Validator.java    → 純靜態方法,不實作任何介面
    // *EventHandler.java → extends AbstractEventHandler,OSGI-INF/*.xml 登錄為 DS 服務
    
    // EventHandler 捕捉 OSGi 事件,呼叫 Validator 的靜態方法做驗證
    @Component(immediate = true, service = IEventHandler.class)
    public class InvoicePrefixEventHandler extends AbstractEventHandler {
        @Override
        protected void doHandleEvent(Event event) {
            String topic = (String) event.getProperty(IEventTopics.EVENT_TOPIC);
            if (IEventTopics.PO_BEFORE_CHANGE.equals(topic)) {
                String err = InvoicePrefixValidator.validateStatusTransition(...);
                if (err != null) throw new AdempiereException(err);
            }
        }
    }

    坑 3:2Pack ZIP 打包方式,犯了兩次

    iDempiere 的 PackIn 解壓 ZIP 到 /tmp/,預期路徑是 /tmp/tw_invoice_system/dict/PackOut.xml

    第一次:ZIP 裡多了 2pack/ 前綴層。第二次:用了 zip -j(junk paths),把所有目錄剝掉,路徑變成 /tmp/PackOut.xml/dict/PackOut.xml——把文件名當目錄了。

    # 正確打包方式
    mkdir -p /tmp/b/tw_invoice_system/dict
    cp PackOut.xml /tmp/b/tw_invoice_system/dict/
    cd /tmp/b && zip -r 2Pack_1.0.10.zip tw_invoice_system/
    
    # 永遠要驗證結構
    unzip -l 2Pack_1.0.10.zip

    坑 4:SeqNoGrid 缺失 → Grid View 崩潰(最燒時間)

    這是整個過程中最「無辜」的 bug——不是邏輯錯誤,是 XML 少了兩個欄位。所有 73 個 AD_Field 元素都缺少 <SeqNoGrid> 和正確的 <IsDisplayedGrid>

    iDempiere 12 的 Grid View 渲染器在初始化行編輯器時需要 SeqNoGrid 做排序依據,全部 NULL 導致:

    java.lang.IndexOutOfBoundsException: Index: 2
        at GridTabRowRenderer.editCurrentRow

    任何視窗,只要在 Grid 模式下按「新增」,必爆。這個 bug 在官方文件裡完全沒有提到。修復:補上這兩個欄位。

    <SeqNo>10</SeqNo>
    <SeqNoGrid>10</SeqNoGrid>        <!-- = SeqNo,顯示欄位 -->
    <IsDisplayedGrid>Y</IsDisplayedGrid>
    
    <!-- 隱藏欄位(SeqNo=0)-->
    <SeqNoGrid>0</SeqNoGrid>
    <IsDisplayedGrid>N</IsDisplayedGrid>

    坑 5:兩個 JVM 搶 Port,Deploy 進錯的那個

    症狀很奇怪:OSGi telnet console 顯示 bundle ACTIVE ✅,但 Web Console 找不到這個 bundle ❌。

    最後發現機器上跑著兩個 iDempiere JVM:

    JVM 擁有 Port 說明
    JVM-A(舊的)8080/8443Web 瀏覽器連這個
    JVM-B(新的)12612OSGi telnet 連這個

    deploy.sh 透過 telnet 把 bundle 裝進了 JVM-B,但使用者看的 Web Console 是 JVM-A。原因是 idempiere-server.sh 有 restart loop,systemctl restart 啟動了新 JVM,但舊 JVM 沒死。

    # 診斷方法
    ps aux | grep java | grep -v grep | wc -l  # > 1 就是這個問題
    
    # 修復:kill 兩個 JVM,等 30 秒讓 port 釋放,再 restart
    sudo kill <pid1> <pid2>
    sleep 30
    sudo systemctl restart idempiere

    坑 6:AD_Field UUID 衝突

    2Pack 重裝時,iDempiere 已為新建的 Tab 自動插入標準欄位(AD_Client_ID、AD_Org_ID、IsActive)。當 PackIn 再次嘗試用不同 UUID 插入同一個 (tab_id, column_id) 組合時,違反了 UNIQUE(ad_tab_id, ad_column_id) 約束,拋出 POSaveFailedException

    解法:對這類「系統可能已存在」的標準欄位,PackOut.xml 使用固定的 placeholder UUID。PackIn 遇到重複就 UPDATE 而不是 INSERT。升版 UUID 策略:已存在的 field → 保留原 UUID;新增的 field → 才用新的 uuid4。不要為了「整齊」換掉既有 UUID。

    坑 7:清除 DB 做全新安裝——FK 刪除順序

    當要做「完整卸載 → 清 DB → 重裝」的驗證時,刪資料的順序錯了好幾次。

    正確順序:AD_Field → AD_Tab → AD_Window,每一步都有 FK 指向下一個。特別注意:AD_PreferenceAD_Menu 也會 FK 到 AD_Window,忘記刪這兩個就卡住。另外:ad_package_imp 記錄了 2Pack 安裝歷史,不清掉的話 Incremental2PackActivator 判定「已安裝過同版本」就跳過不執行。

    如果重來一次,我們會怎麼做

    1. 先建立 PackOut.xml 驗證腳本

    每次 2Pack 安裝後自動跑這些 SQL,出問題立刻知道,不用等到 UI 爆炸:

    -- SeqNoGrid 是否設定
    SELECT tablename, count(*) FILTER (WHERE seqnogrid > 0) ok
    FROM ad_table JOIN ad_tab ... JOIN ad_field ...
    WHERE tablename LIKE 'TW_%' GROUP BY tablename;
    
    -- _UU 欄位是否 updateable
    SELECT columnname, isupdateable FROM ad_column
    WHERE tablename LIKE 'TW_%' AND columnname LIKE '%_UU';

    2. 把 ZIP 結構驗證寫進 Maven build

    <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>exec-maven-plugin</artifactId>
      <executions>
        <execution>
          <phase>verify</phase>
          <goals><goal>exec</goal></goals>
          <configuration>
            <executable>bash</executable>
            <arguments>
              <argument>-c</argument>
              <argument>unzip -l resources/META-INF/2Pack_*.zip | grep -q "dict/PackOut.xml"</argument>
            </arguments>
          </configuration>
        </execution>
      </executions>
    </plugin>

    3. 每次 commit 前跑 deploy.sh –check

    加一個 dry-run 模式,只驗證 JAR 可部署、OSGi console 可連線、bundle 存在,不實際更新。讓這個檢查成為 commit hook。

    給下一個要做 iDempiere Plugin 的人

    iDempiere 的文件很少,很多行為只有讀原始碼才能理解。以下是花最多時間搞懂的六件事:

    # 規則 說明
    1ModelValidator 不是 OSGi 服務@Component 不會讓它跑起來,要用 EventHandler
    2SeqNoGrid 是 Grid View 必備欄位缺了不報錯,只在按「新增」時崩潰
    32Pack ZIP 結構有嚴格要求打包後一定要 unzip -l 驗證,絕不用 zip -j
    4_UU 欄位必須 IsUpdateable=Y否則 UUID 永遠 NULL
    5IEventTopics 常數不要用字串字面量比較 topic,靜默失效
    6Incremental2PackActivator 記住安裝歷史同版本不重裝,升版要改 ZIP 檔名

    後記:實作兩個流程(又踩了三個坑)

    文章發完當天,隨即著手實作原本標注為「計劃中功能」的兩支 SvrProcess

    • GenerateTaxStatementProcess — 聚合 TW_Invoice_Prefix_Map 的銷售資料、折讓,產生 TW_TaxStatement 申報記錄
    • ExportTaxReportProcess — 讀取 TW_TaxStatement,輸出財政部格式 CSV

    同時也需要把這兩個流程透過 2Pack 登錄到 iDempiere 的 AD_Process / AD_Menu,讓使用者可以從選單觸發。這一輪又多踩了幾個坑。

    坑 8:AD_Process_Para 的 AD_Process_ID 必須明確寫入

    2Pack 的元素處理器(ElementHandler)有一個隱藏的不一致性

    AD_Tab 時,把它放在 <AD_Window> 元素內,Tab 的 AD_Window_ID 會自動繼承父元素——不需要重複宣告。大多數巢狀元素都這樣工作。

    AD_Process_Para 不同。ProcessParaElementHandler 呼叫 filler.autoFill() 處理子元素,但不從父 <AD_Process> 讀取 context 填入 AD_Process_ID

    結果:2Pack 安裝過程看起來正常執行,沒有任何錯誤訊息,但 Process Para 根本沒有存入。直到手動查 DB 才發現空的。真正的錯誤需要翻 PostgreSQL log:

    tail -f /var/log/postgresql/postgresql-16-main.log
    # ERROR: null value in column "ad_process_id" violates not-null constraint

    修正:每個 <AD_Process_Para> 元素內都必須顯式宣告 AD_Process_ID

    <AD_Process_Para type="table">
      <AD_Process_ID reference="uuid" reference-key="AD_Process">{process-uuid}</AD_Process_ID>
      <Name>Statement Year</Name>
      ...
    </AD_Process_Para>

    坑 9:FieldLength NOT NULL(但 iDempiere log 不說)

    修好 AD_Process_ID 之後,再次安裝,再次失敗,再次查 PostgreSQL log:

    ERROR: null value in column "fieldlength" violates not-null constraint

    FieldLengthad_process_para 資料表中是 NOT NULL 欄位,但如果 PackOut.xml 沒有提供,iDempiere 的 log 只會說 Failed to save ProcessPara——沒有欄位名稱,沒有 SQL,什麼都沒有。

    不同 Reference 型別的預設長度:

    AD_Reference_ID 型別 FieldLength
    11Integer10
    17List1
    10String實際最大長度

    教訓:2Pack 的錯誤訊息有時候刻意模糊。遇到 Failed to save 之類的通用錯誤,直接去查 PostgreSQL log,那裡才有真相。

    坑 10:iDempiere 物理表在 adempiere schema,不在 public

    寫完 clean_reinstall.sh(一個用來清除所有 TW_* 字典並重新部署的腳本)後,發現 DROP TABLE 完全沒作用:

    DROP TABLE IF EXISTS TW_InvoicePrefix;  -- 執行成功,但表還在

    原來 iDempiere 12.0 把物理表建在 adempiere schema,而不是 public。用 information_schema.tables WHERE table_schema='public' 查詢,一張 TW_* 表都找不到。

    正確用法:

    -- 確認表存在
    SELECT tablename FROM pg_tables WHERE schemaname='adempiere' AND tablename ILIKE 'tw_%';
    
    -- 刪除表
    DROP TABLE IF EXISTS adempiere.TW_InvoicePrefix;
    DROP TABLE IF EXISTS adempiere.TW_Invoice_Prefix_Map;

    這也影響 psql 互動查詢——連線後預設 search_path 如果不含 adempiere,直接 SELECT * FROM TW_InvoicePrefix 會找不到表。

    SvrProcess 實作要點

    SvrProcess 的標準結構很直覺——prepare() 讀參數、doIt() 做事。幾個需要注意的地方:

    • 不要呼叫 ps.setAD_Client_ID():那是 PO 類別的 protected 方法,不是 PreparedStatement 的方法。在 SvrProcess 裡用 getAD_Client_ID() 取值,直接 ps.setInt(1, getAD_Client_ID())
    • DB.prepareStatement() 而不是 JDBC 直接連線:iDempiere 的 DB class 管理連線池和事務,不要繞過它。
    • 記得 DB.close(rs, ps):在 finally block 釋放資源。

    clean_reinstall.sh — 開發期間的救命工具

    開發期間反覆修改 PackOut.xml,每次都要手動清資料庫重裝,非常繁瑣。寫了一個腳本自動化整個流程:

    1. 依 FK 順序刪除所有 TW 字典(Window_Access → Process_Access → Field → Tab → Menu → Window → Process_Para → Process)
    2. Drop 物理表(adempiere.TW_*
    3. 清除後設資料(Column → Table → Sequence → Element → Reference → EntityType)
    4. 清 AD_Package_Imp_Detail / AD_Package_Imp(注意:Detail 要先刪,因為有 FK)
    5. 呼叫 deploy.sh 重新部署

    FK 刪除順序是最麻煩的部分——錯一個順序就會碰到 FK 違規,整個腳本失敗。從失敗中整理出來的正確順序如上。

    最終成果(v1.0.11)

    Bundle:    tw.idempiere.invoice.tax v1.0.0 (2Pack v1.0.11)
    Tests:     89 個,全數通過
    Tables:    4 張 TW_* 資料表
    Windows:   4 個 iDempiere 視窗
    Processes: 2 個(GenerateTaxStatement + ExportTaxReport)
    Fields:    73 個 AD_Field(含正確 SeqNoGrid)
    Menu:      7 個項目(1 父選單 + 4 視窗 + 2 流程)
    Status:    ACTIVE,Grid View 正常,流程可從選單觸發
  • 認知與社交情緒發展:思考力、專注力、情緒調節指南

    🧠 孩子的認知、社交、情緒發展正常嗎?本文整理 0-6 歲認知與社交情緒發展里程碑,包含 Parten 遊戲階段理論、情緒調節四步驟,以及專注力發展對照。

    (閱讀全文…)

  • 托嬰、托幼、幼兒園完整指南:選園、適應期、分離焦慮

    🏫 托嬰中心、保母、幼兒園怎麼選?本文完整比較台灣各類托育選項、選園必查事項、入園準備清單,以及分離焦慮處理與適應期陪伴技巧。

    (閱讀全文…)

  • 0-6歲飲食完整指南:副食品、挑食處理、營養均衡

    🍼 副食品什麼時候開始?挑食怎麼處理?本文提供 4-6 個月到 6 歲的完整飲食指南,包含食物質地進程、過敏原引入建議、挑食應對策略。

    (閱讀全文…)

  • 語言發展里程碑:0-6歲寶寶說話能力完整追蹤

    🗣️ 孩子幾歲會說話?詞彙量夠不夠?本文整理 0-6 歲語言發展里程碑,幫助你追蹤孩子的語言進度,了解何時需要評估,以及如何促進語言發展。

    (閱讀全文…)

  • 動作發展與生活自理:翻身、爬行、走路到如廁訓練

    🏃 孩子幾個月會翻身、爬、走?本文整理 0-6 歲粗大動作與精細動作發展里程碑,包含如廁訓練完整指南、生活自理能力培養,以及發展警訊。

    (閱讀全文…)

  • 兒童緊急狀況處理手冊:急救、CPR、燙傷完整指南

    🚨 孩子噎到、燙傷、撞頭怎麼辦?學會正確的急救步驟,關鍵時刻能救命。本文包含哈姆立克法、嬰幼兒 CPR、燙傷沖脫泡蓋送等完整圖解。

    (閱讀全文…)

  • 小孩生病了怎麼辦?發燒、感冒、腸胃炎完整處理指南

    🤒 孩子發燒、咳嗽、拉肚子怎麼辦?本文整理台灣兒科醫學會建議,教你判斷何時該就醫、居家照護要點,以及常見迷思破解。

    (閱讀全文…)