前兩天，我先定稿四位虛構個案、四種工作狀態、四題關懷問題與五種回答狀態。這些資料已經集中在固定檔案裡，但 CareCall AI 仍只有今日總覽真正呈現內容。今天的任務，是讓五個核心區域開始使用同一份可變資料，而不是各自複製一份看起來相同的 Demo。

如果每個畫面都有自己的個案陣列，初始畫面可能完全一樣，問題卻會在修改後出現。例如人工處理中心把陳明德改成「已完成」，總覽可能仍顯示「待人工確認」，個案詳細也可能保留舊狀態。使用者看到的是同一個人，程式底下卻是三份互不相干的資料。

今天我建立了 CareDataProvider，集中管理四位個案、四題問題、目前選取個案與狀態修改方法。五個區域都透過同一個 useCareData 介面讀取資料，不再自行建立另一份假資料。狀態修改也抽成獨立的純資料函式，讓更新規則可以被檢查與重複使用。

這次五個區域只做到足以驗證資料流的最小內容。今日總覽顯示個案與狀態統計；個案詳細顯示四題原文、整理值與缺漏；關懷腳本顯示 Day 9 定稿的四題；文字／語音關懷目前只呈現回答紀錄，沒有假裝語音或 AI 已完成；人工中心則從同一份個案資料中篩選「待人工確認」與「優先處理」。

同步驗收以陳明德為例。他一開始是「待人工確認」，在人工中心標記完成後，今日總覽的完成數應從一變成二，待人工確認數量變成零；個案詳細也應立即顯示「已完成」，人工中心則不再列出他。這些變化不需要逐頁手動更新，因為所有畫面讀取的是同一個狀態。

今天的狀態只保存在瀏覽器記憶體，重新整理後會恢復初始 Demo。這是刻意的範圍控制：永久保存與重設功能會依後續日程處理，今天先證明資料只有一份，而且跨畫面同步成立。

這一步也讓我理解，「重複內容」和「共用資料」並不相同。複製貼上可以快速做出五個相似畫面，卻會把未來每次修改變成五次工作。建立單一資料來源看起來沒有華麗的新功能，但它讓後續規則、人工處理、語音與 AI 都能建立在一致的事實上。

今日反思

真正的一致不是五個畫面同時顯示相同文字，而是資料改變一次後，所有需要知道這件事的地方都得到同一個結果。