公益共創平台 MIS 架構 2.0（示範版）

一頁摘要

先看這一頁

專案定位不是 CSR 展示網站，也不是照片管理系統，而是「公益參與與分享平台」。
參與的定義消費本身就是公益參與；拍照合影是進一步的響應；分享讓真實消費者成為晴光理念的傳播者。
系統要管的鏈消費 → 響應 → 分享 → 導流 → 新參與。每一段都要留得下資料、追得到來源。
第一版就要預留每個分享頁的唯一 share_id，以及每張照片的授權等級與下架機制。
開發順序Phase 1 公益資料平台 → Phase 2 讓消費者找到自己並分享 → Phase 3 建立善的蝴蝶效應。
要交的 KPI第十章的七個數字，不是 PV、UV、上傳照片數。
可行性八成可以直接長在現有的 LINE bot 與靜態站上。卡點是 POS 資料、授權要有人按、社群平台限制，詳見第十二章。

第一層消費公益消費參與。在晴光完成消費，透過 Buy for Good 參與公益。主要指標公益消費參與人次
第二層響應願意進一步合影、參與活動、Run for Good 等。主要指標公益共創響應人次
第三層分享使用者把自己的公益參與分享到個人社群。主要指標公益分享人次、公益分享率
第四層影響分享帶來瀏覽、認識、再參與。主要指標公益內容觸及、分享導流人次、新公益參與

第一章

專案定位

這個平台不是單純的公益網站，也不是照片管理系統。真正的目的，是建立一條完整的消費者公益旅程：

消費
公益參與
拍照響應
找到自己的照片
分享到個人社群
朋友看見
認識晴光
認同晴光
選擇晴光消費
更多公益力量

Phase 1 已涵蓋，或分享之後自然發生2.0 新增的關鍵段落

最終希望達成的，不是由晴光自己告訴大家「我們在做公益」，而是讓真實消費者因為親自參與、產生認同，願意主動分享給自己的朋友、同學、同事與家人。這樣的分享比企業廣告更有真實感，也更有機會建立品牌信任與認同。

對 MIS 的意義

照片只是載體。系統除了管理照片，更重要的是把「消費 → 響應 → 分享 → 導流 → 新參與」整條鏈管起來、追得到，最後能用數據回答：有多少消費者因為認同 Buy for Good 而替晴光分享，又有多少新的人因為朋友的分享而開始認識並支持晴光。

第二章

品牌與公益架構

Buy for Good

消費做公益

消費者每一筆在晴光的消費，晴光將該筆消費所產生獲利的

20%五分之一

投入公益，主要支持國內弱勢兒童與孩童教育。

消費者的核心理解：我本來就要買東西，不需要多付錢，只要選擇在晴光消費，就能讓這筆消費同時產生公益價值。

Run for Good

企業結盟公益路跑

晴光與外部企業、合作夥伴共同結盟舉辦的公益路跑。

是消費之外的第二種參與方式：用行動參與。在資料四層裡屬於「響應」，也是分享導流之後希望帶來的「新參與」之一。

兩者最後都回到守護孩子的大未來

第三章

核心使用情境

開發時，請先以這個完整情境設計，而不是先想頁面。前四步是 Phase 1 的範圍，第五、六步是 2.0 新增、也是最重要的部分。

1

消費者在晴光完成消費 Phase 1

這一筆消費本身就屬於「公益消費參與」。不需要拍照、不需要登錄，消費就已經參與。
2

門市邀請消費者公益合影 Phase 1

店員邀請：「您今天的消費也一起參與了晴光公益，如果願意，可以一起留下這次公益參與紀錄。」消費者拿手拿旗拍照。
3

門市上傳照片 Phase 1

門市透過手機版 Web 操作：

拍照／選照片確認門市填寫參與人次確認公開授權上傳

系統自動建立一筆「公益共創響應紀錄」。
4

照片進入公益共創平台 Phase 1

照片經過「上傳 → 審核 → 公開」後進入公益共創響應牆。前台不需要一次顯示很多張，維持目前概念：一次 3～4 張輪播即可。
5

消費者回到平台，找到自己的照片 Phase 2 新增

用 QR Code、門市＋日期或公益參與編號找到照片，進入專屬的「個人公益參與頁」，看到自己的公益參與紀錄。
6

一鍵分享到個人社群 Phase 2 新增

分享到 LINE、Facebook、Threads，或複製連結、下載分享圖上傳 IG。每一次分享都帶唯一的追蹤碼，讓後續的點擊、新訪客與新參與能被追回來。

第四章

消費者端功能

4.1 找我的公益照片

這是整個平台最關鍵的第二階段。消費者回到網站後，要有「找我的公益照片」入口。建議提供三種方式：

方法	消費者怎麼做	系統要做什麼	評估
A｜QR Code	拍照完成後，掃店員提供的 QR Code	QR 帶入「門市＋日期」，進入後只看到當天該店的照片	搜尋難度最低，第一版採用
B｜門市＋日期搜尋	選擇門市（例：○○店）、選擇日期（例：2026/09/03）	顯示當天經授權公開的照片	成本最低，第一版採用
C｜公益參與編號	輸入拍照後取得的編號（例：No. 012865）	拍照時產生「公益共創響應 No.」，以編號直接對應一筆響應紀錄	需在門市端產生並交付編號，可於 Phase 2 後段加入

建議

第一版採 QR Code＋門市＋日期，最簡單、成本也最低。編號制可以先在資料結構預留欄位，介面後補。

4.2 個人公益參與頁

消費者找到自己的照片後，不只是看大圖，而是進入一個專屬頁面。這一頁是分享的起點。

❤️ 我的公益共創紀錄

2026 公益共創響應者

No. 012865

顧客本人合影照片

2026/09/03　晴光 XX 店

今天，我和晴光一起
用消費改變世界

目前已有 XXX 萬 公益消費參與人次
XX 萬 公益共創響應人次

分享我的公益參與

頁面內容

標題我的公益共創紀錄
身分2026 公益共創響應者，加上公益參與編號
照片該筆響應紀錄的合影
紀錄日期與門市
一句話今天，我和晴光一起用消費改變世界
即時總數目前的公益消費參與人次、公益共創響應人次
主要按鈕分享我的公益參與

頁面的主角是消費者本人，不是晴光。晴光的品牌與數字放在次要位置。

4.3 分享到個人社群

平台應支援：

LINE
Facebook
Threads
複製連結
Instagram：下載分享圖／產生限時動態圖片，由使用者自行上傳

IG 因平台限制無法直接帶連結分享，改成產生一張限時動態尺寸的圖片讓使用者下載。

文案原則

按鈕不要寫「分享晴光活動」，要寫「分享我的公益參與」。心理完全不同：前者是替晴光打廣告，後者是表達自己的價值選擇。後者才比較容易產生自然分享。

4.4 分享出去的內容：Social Share Card

系統自動產生分享卡，搭配顧客本人的照片。文案的重點是「我的選擇」，不是「晴光的活動」。

分享卡內容

主標今天，我讓這次消費多了一份意義
身分2026 公益共創響應者，No. 編號
照片顧客本人合影
一句話我本來就有消費需求，選擇在晴光，也能一起做公益。
品牌落款Buy for Good｜用消費改變世界｜守護孩子的大未來

這樣他不是在「替晴光打廣告」，而是在「表達自己的價值選擇」。分享頁需要對應的 Open Graph 圖片與標題，貼到 LINE、Facebook、Threads 時才會正確顯示這張卡。

第五章

分享連結一定要可追蹤

這一點要在第一版的資料結構就預留。每一個分享頁產生唯一的 share_id（tracking code）。系統至少要能知道：

哪一筆公益響應產生了分享
分享時間
分享渠道（LINE、Facebook、Threads、複製連結、下載圖）
分享頁被點擊幾次
帶來多少新訪客
新訪客後續是否瀏覽 Buy for Good
是否進一步參加活動／Run for Good

未來才能真的回答：一個消費者的分享，究竟帶來多少新的公益認識與參與？這就是「蝴蝶效應」的量化。

第六章

系統核心資料分四層

資料架構直接按照這四層設計。整套數據邏輯就是：消費 → 響應 → 分享 → 影響。

第一層消費公益消費參與資料來源POS／交易系統主要指標公益消費參與人次
第二層響應願意進一步合影、參與活動、Run for Good 等資料來源門市上傳的響應紀錄、活動報名主要指標公益共創響應人次
第三層分享使用者將參與分享到個人社群資料來源分享頁的 share_id 與分享事件主要指標公益分享人次、公益分享率
第四層影響分享帶來瀏覽、認識、再參與資料來源分享連結的點擊與新訪客後續行為主要指標公益內容觸及、分享導流人次、新公益參與

兩個人數不要混在一起

公益消費參與人次

所有在晴光完成消費、透過 Buy for Good 參與公益的消費人次。

第一層｜來自 POS／交易系統

公益共創響應人次

在公益消費之外，又進一步透過合影、活動等方式公開響應的人次。

第二層｜來自門市上傳與活動報名

不是拍照了才叫參與公益。消費本身已經是公益參與；拍照代表從參與進一步走向認同與響應。這兩個數字在資料表、Dashboard 與前台都要分開呈現。

第七章

各端介面需求

7.1 消費者前台首頁

第一屏
同樣一次消費，也能多一份意義
在晴光消費，您不需要額外多付一筆錢；晴光將企業獲利的 20% 投入公益，支持國內弱勢兒童與孩童教育。
了解 Buy for Good
第二區
三個主要大數字
公益消費參與人次公益共創響應人次累積公益投入金額本月分享人次社群觸及人次
三個大數字為主，旁邊放兩個小數據。
第三區
公益共創響應牆
3～4 張真實顧客照片輪播。
找我的公益照片
第四區
公益真的去了哪裡？
呈現孩子、教育、實際公益成果與故事。否則消費者只看到數字，會不知道公益最終產生什麼改變。
第五區
我也想加入
三個入口。
用消費參與｜Buy for Good用行動參與｜Run for Good分享我的公益參與

7.2 門市端

第一版做到非常簡單。門市首頁只顯示三個數字，下面一個「上傳照片」按鈕。

今日公益共創響應
XX人次
本月
XXX人次
今年
XXXX人次

上傳欄位（橘線為授權欄位，第一版必填）

門市
日期
參與人數
照片
公開授權
活動分類
上傳同仁
備註

7.3 總部 Dashboard

提供真正有管理價值的數字，分五組：

公益成果
- 累積公益投入
- 公益專案
- 受益成果
公益參與
- 公益消費參與人次
- 公益共創響應人次
公益傳播
- 分享人次
- 分享率
- 分享導流
- 社群觸及
門市
- 參與門市
- 各店響應
- 區域趨勢
Run for Good
- 參與企業
- 跑者人數
- 活動成果

第八章

照片授權與隱私，從第一版就做

這不是最後才補的東西。每筆照片至少要有一個授權等級，由限制最嚴到最開放：

未授權
僅內部使用
同意公開於公益平台
同意社群／宣傳使用

限制最嚴最開放

授權流程依實際法務需求設計；只有達到「同意公開於公益平台」以上的照片，才會進入響應牆與找照片的結果。
若涉及兒童／未成年人，另外建立更嚴格的公開與授權規範。
消費者要有「取消公開／申請下架」的機制，下架後分享頁與分享卡也要一併失效。

第九章

建議開發順序

Phase 1

建立公益資料平台

先把資料與照片的底層做穩

門市照片上傳
授權
照片審核
公益共創響應牆
2026 公益數據
Dashboard
電視牆

這一階段產生：可信的公益資料底層，以及第二階段需要的響應紀錄與授權欄位。

Phase 2 ・下一個最重要階段

讓消費者找到自己並分享

從「晴光說」變成「消費者說」

找我的照片
QR Code
個人公益參與頁
公益參與編號
Share Card
LINE／FB／Threads 分享
分享追蹤

這一階段真正開始產生 Consumer Advocacy：消費者主動替品牌傳播。

Phase 3

建立善的蝴蝶效應

把分享帶來的人接住，變成新參與

Buy for Good 完整專區
Run for Good
公益成果故事
LINE OA
活動報名
企業合作
分享導流分析
新參與轉換分析

這一階段產生：可量化的蝴蝶效應，證明分享真的帶來新的認識與參與。

第十章

這個專案最重要的 KPI

不要只交 PV、UV、上傳照片數。真正要交的是下面七個數字，它們才有機會證明「善的蝴蝶效應」是否真的發生。

#	指標	定義／公式	所屬層
1	公益消費參與人次	所有透過 Buy for Good 參與公益的消費人次	消費
2	公益共創響應人次	進一步以合影、活動等方式公開響應的人次	響應
3	公益響應率	公益共創響應人次 ÷ 公益消費參與人次	響應
4	公益分享人次	將自己的公益參與分享到個人社群的人次	分享
5	公益分享率	公益分享人次 ÷ 公益共創響應人次	分享
6	分享帶來的新訪客	經由帶 share_id 的分享連結進站的新訪客	影響
7	分享帶來的新參與	新訪客後續的公益參與：瀏覽 Buy for Good、報名活動、Run for Good 等	影響

第十一章

給資訊同仁的專案說明

下面這段可以直接轉貼給 MIS，作為需求書的開場。

這個專案不是要做一個展示晴光公益成果的 CSR 網站，而是要建立一套「公益參與與分享平台」。

消費者原本就有消費需求，透過 Buy for Good，在晴光消費的同時就能參與公益。我們希望在這個基礎上，再讓願意進一步響應的消費者留下公益合影。

拍照之後，消費者可以回到平台找到自己的照片，看到自己的公益參與紀錄，再一鍵分享到自己的 LINE、Facebook、Threads 或其他個人社群。

我們希望未來不是晴光自己透過媒體告訴大家「晴光做公益」，而是讓一位真實消費者告訴他的同事、同學、朋友：

「我知道晴光在做什麼，我認同這樣的企業，而且我今天也參與了。」

當一個人的分享帶來下一個人的認識、認同、消費與公益參與，就形成我們希望建立的「善的蝴蝶效應」。

因此系統除了管理照片，更重要的是必須能管理與追蹤：消費 → 響應 → 分享 → 導流 → 新參與。

最後讓公司可以用數據清楚知道：到底有多少消費者因為認同 Buy for Good，而願意替晴光分享；又有多少新的人因為朋友的分享，而開始認識並支持晴光。

第十二章

可行性評估：哪些我們能做

以 2026-09 的系統現況為準。結論：2.0 大約八成可以直接長在現有的 LINE bot 與靜態站上。卡住的不是技術，是三件事：POS 資料、授權要有人按、社群平台本身的限制。

系統現況

示範版省略客戶內部系統現況（門市上傳流程、託管方式、金鑰位置、資料模型缺口）。正式文件在這裡逐條列出「已有什麼、缺什麼」，作為下方可行性判斷的依據。

直接能做現有系統改一改

幾天到一週，不需要新的基礎設施。

授權欄位與審核資料欄位、稽核欄位、寫入函式都在，只是沒人寫入。加回一顆「顧客同意公開」按鈕或改由總部審，再讓響應牆與電視牆只吃 public。
參與人次、上傳同仁人次修正與統計管線完整，只缺輸入；上傳同仁本來就有存。
活動分類、備註新欄位，用 LINE 指令或按鈕收。
電視牆已上線。
2026 公益數據Google Sheet → RTDB → 網站的管線已在跑。
QR Code每店一張固定 QR 連到找照片頁，日期預設當天；用現有 Pillow 產 50 張。
門市＋日期搜尋bot 加一個 JSON 端點。要另建一個不隨年度清理、只含 public 照片的公開索引，展示圖也要另存一份。
LINE、FB、Threads、複製連結純前端。
Share Card、IG 限時動態圖build 已在用 Pillow，多一支產圖程式，放 Noto Sans TC 字型檔。
首頁五區、專區與故事頁Sanity 加 build.py，內容工作大於工程。
GA4DEPLOY.md 已決定用 GA4，只差把 gtag 貼進 layout。

能做，先補基礎一到三週的工程

要新增會寫資料的端點，或一個有登入的後台。

個人公益參與頁每筆紀錄一頁，貼到 LINE、FB 要有正確 OG，靜態站做不到即時。建議做在 bot 的 Cloud Run 上，它已經會出 HTML，不必另起 Pages Functions。
公益參與編號RTDB transaction 做流水號即可。先決定編號能不能被猜到，它會變成找照片的鑰匙。
分享追蹤短網址 /s/{share_id} 做在 bot 上，點擊記到 RTDB，落地頁帶 UTM 給 GA4。這是 2.0 工程量最大的一塊。
總部 Dashboard、審核後台從零開始的 Web 後台，要有登入。bot 網域沒走 Cloudflare，用 Google 登入限制 @example.com 最省；資料讀 RTDB。
門市 Web 版上傳能做，但 LINE 流程已跑順且 50 店都註冊了。建議不換，Web 版當補充。
消費者申請下架下架指令已有、秒級生效。消費者端要一個表單加人工執行；下架後個人頁與分享圖要一起失效。
用量與安全網站每個訪客都直接讀 RTDB，分享流量上來後頻寬與公開讀取的風險要重看。照片紀錄留在 RTDB 與 GCS 是對的，不要搬進 Sanity 免費方案。

有條件技術在我們，資料或決策在別人手上

要先拿到資料、條款或一個決定，才能動工。

公益消費參與人次現在是行銷在 Sheet 手填。要即時就要 POS 或 ERP 出報表或 API；我們做匯入端，口徑與資料授權要 POS 主管與財務定。
累積公益投入金額財務數字，只能定期人工更新，走現有 Sheet 管線。
授權文字、兒童規範、下架時效法務。我們做欄位與流程，不寫條款。
審核要有人按總部要指定審核者。沒有人按，同意公開永遠不會發生，這正是今天全部 internal 的原因。
店員要多一個動作8 月 30 日的決策是零互動。要授權就一定多按一次，或改由總部審。這是營運決策。
LINE OA同一個 channel 就能推播，超過免費額度要付費。若開 LINE Login 讓消費者綁定自己的照片，找照片可以全自動，值得列為 Phase 2 選項。
活動報名與收費報名表能做，金流要簽第三方，個資要有保存政策。若報名放外部平台，分享導流到報名的歸因就斷了。
Share Card 設計與文案設計與行銷。

做不到，或做不準平台限制，或沒有資料來源

要改 KPI 的定義，或接受近似值。

IG 直接分享帶連結平台不開放，只能下載圖。
FB 分享預填文字FB 只吃 OG 卡；Threads 與 LINE 可以帶文字。
社群觸及人次LINE、FB、Threads 不會回傳個人貼文被多少人看到，只算得到連結點擊。這個 KPI 要改定義成分享頁點擊。
新參與若是「到店消費」無法歸因，除非分享頁附優惠碼由 POS 刷入，那是 POS 改造。
跨裝置辨識同一個新訪客沒有登入只能用 cookie 近似。
拍照率、店員邀請率門市管理，不是系統。

建議的動手順序

1
先把授權補回來
一顆按鈕加牆面過濾。所有 Phase 2 的前提，也是現在文案與程式不一致的缺口。
2
GA4 貼上
開始累積基準值。
3
個人頁、分享按鈕、短網址追蹤一起做在 bot 上
同一個 Cloud Run 服務，一次到位。
4
QR 與門市日期搜尋
依賴第 1 步的 public 索引。
5
Dashboard 後台
審核與數字放同一個地方。
6
POS 資料另開會議
不要讓它卡住前面五項。

第十三章

要向各單位索取的資料

對應第十二章的動手順序。每一項寫清楚給誰、要什麼、什麼形式、什麼時候要，可以直接轉成需求信。先列開工前一定要有的，其餘邊做邊補。

開工前一定要有

總部營運審核者名單：姓名、LINE UID、能做「同意公開」與「下架」的範圍。沒有這份，授權永遠不會發生。
總部營運一個書面決定：店員上傳後多按一次「顧客同意公開」，或全部改由總部審。
法務授權四級的對外文字、未成年人規範、下架流程與時效。
財務20% 公益投入的計算口徑與可引用來源，個人頁與分享卡都要寫這句話。
專案 owner公益參與編號規則，以及同意把「社群觸及人次」改定義為「分享頁點擊」。
帳號持有人GA4 資源的編輯權限，以及 Google Cloud 專案帳單擁有者是誰。

財務／會計

要提供什麼	形式	何時要	用在哪
歷年公益投入金額	公司與董事長個人分列、含截至日期；Excel 或填現有 KPI Sheet	第 2 步前	首頁大數字、Dashboard 公益成果、Sanity 逐年捐款
20% 的計算口徑與來源	一段可對外的文字加來源連結或文件	開工前	首頁第一屏、個人頁、Share Card 文案
更新頻率與負責人	一個名字加頻率	開工前	KPI Sheet 維護

POS／ERP

要提供什麼	形式	何時要	用在哪
公益消費參與人次的口徑	一頁定義：以交易、發票或會員計；是否含線上購物與退貨	第 6 步會議前	KPI 1、公益響應率的分母
歷史累計值與每月新增	分門市；最低每月一個數字填 Sheet，理想是每日自動匯出 CSV，欄位為日期、門市代碼、筆數	第 6 步	首頁大數字、Dashboard
門市代碼與名稱對照	一張表，含區域，與 bot 現有 50 店對齊	第 5 步前	Dashboard 區域趨勢、資料對接
優惠碼能否在結帳輸入並回報	可或不可，加限制說明	Phase 3	到店消費歸因，選項

行銷／公益團隊

要提供什麼	形式	何時要	用在哪
首頁五區與專區文案定稿	Word，或直接進 Sanity；之後要英文版	第 2 到 3 步	首頁、Buy for Good 專區
受益成果	學校數、受益人次、公益專案清單、成果故事與照片，照片要附授權說明	第 3 步後	第四區「公益去了哪裡」、Dashboard 受益成果
Run for Good 資料	2026 場次、參與企業名單、報名放外部平台或自建的決定	Phase 3	專區、Dashboard、導流歸因
社群帳號清單	FB 粉專、Threads、IG、LINE OA 的網址與 ID	第 3 步	分享文案、OG、分享按鈕
Share Card 與個人頁視覺定稿	品牌素材 repo 已有，只需確認文案與版面	第 3 步	產圖程式
KPI Sheet 維護人與更新頻率	一個名字加頻率	開工前	現有 Sheet 到 RTDB 的管線

法務／稽核

要提供什麼	形式	何時要	用在哪
授權四級的對外文字	店員口頭邀請語、門市告示、同意書三個版本	第 1 步前	上傳流程、個人頁授權說明
未成年人規範	一頁：是否需家長同意、是否一律不公開	第 1 步前	授權預設值、審核規則
下架流程與時效	一頁：申請管道、身分確認方式、幾個工作日內完成	第 3 步前	消費者下架表單、SLA
個資告知事項與隱私權政策	定稿文字	第 3 步；Phase 3 報名前	下架表單、活動報名頁

總部營運／門市管理

要提供什麼	形式	何時要	用在哪
審核者名單	姓名、LINE UID、可做「同意公開」與「下架」的範圍	第 1 步前	bot 管理員權限
店員動作的決定	書面：多按一次，或改由總部審	第 1 步前	LINE 上傳流程
50 店清單核對	名稱、代碼、區域，以及開店與閉店異動的通知方式	第 4 步前	QR 產製、搜尋選單、Dashboard
QR 立牌與小卡的印製安排	誰印、每店幾份、送到哪	第 4 步	QR 上線
電視牆展示地點清單	清單	邊做邊補	電視牆

專案 owner／高層

要提供什麼	形式	何時要	用在哪
公益參與編號規則	決定：格式，以及能否被猜到	第 3 步前	編號、找照片
「社群觸及人次」改定義	同意改為「分享頁點擊」	第 3 步前	KPI 定義
預算上限	LINE OA 推播、金流手續費、雲端用量三個數字	Phase 3 前	LINE OA、活動報名、擴容
Phase 時程確認	決定	開工前	排程

帳號與權限

要提供什麼	形式	何時要	用在哪
GA4	舊資源 G-XXXXXXXXXX 的編輯權限，或決定新建資源	第 2 步	GA4
Google Cloud 專案帳單擁有者	一個名字	開工前	Cloud Run、RTDB、GCS 費用歸屬
LINE Developers provider 管理員	邀請；做 LINE Login 要新建 channel 才需要	Phase 2 選項	LINE Login
Facebook 粉專管理員	邀請；分享除錯用，非必要	第 3 步	OG 除錯

第十四章

現在就能開工的事

第十三章的清單寄出去之後，不必等回覆就能動的事。原則是：程式先做、開關先關、文案先用暫代、定稿再換。

兩個設計選擇，讓「要等的決定」變得不用等

編號同時存兩種：流水號給顯示用，例如 No. 012865；不可猜的短碼當網址鑰匙。之後不管怎麼決定都不用改。

授權店員按鈕與總部指令兩條路都做，放在設定開關後面；牆面只顯示 public 也用開關。決定下來當天切，不用重新開發。

這週就能開不用等任何人

寄出第十三章的需求清單越早問越早拿到；POS 與法務通常最慢，先發。
GA4DEPLOY.md 記的舊量測 ID 直接貼進 layout，資料先累積；報表權限另外要。
授權機制的程式按鈕的 postback 處理、總部 #公開指令、consent 與稽核欄位寫入。開關預設關。
長期 public 索引consent 變 public 時寫進一個不隨年度清理的節點，展示圖另存一份；找照片與牆面之後都讀這裡。
測試資料用現有 seed 腳本建一個測試店與幾筆 public 紀錄，開發全程用它，不碰正式資料。
QR 50 張config.py 已有店碼，連到 /find/?s=店碼。先產圖，印製等營運安排。
找照片頁 /find/門市下拉加日期，讀 public 索引；沒資料就顯示「這天還沒有公開照片」。
RTDB 用量與安全盤點看現在的讀取量與規則，決定公開索引要不要改走 bot 端點加快取。

接著做用暫代內容先建，定稿再換

個人公益參與頁 /p/短碼bot 出 HTML 加 OG 標籤；20% 那句先用架構文件的版本，財務定稿再換。
分享按鈕與短網址 /s/share_id建分享紀錄、記點擊、帶 UTM 轉到個人頁。渠道固定五種，不用等社群帳號清單。
Share Card v1Pillow 產圖，用 repo 裡的品牌素材與 Noto Sans TC；版面先照 4.4 的示意。
Dashboard v1用 Google 登入限制 @example.com 的頁面，讀現有的每日、每月、累計統計；區域趨勢那一格等對照表。
下架申請表單bot 收表單、通報到現有的回報群組；流程與時效文字等法務。
Sanity 專區骨架Buy for Good 專區、Run for Good 頁（歷屆資料已在後台）、首頁文案搬進後台；文字先用現有 JSON。

要等做好就停在開關前

牆面只顯示 public 的開關等審核者名單，或店員按鈕的決定。決定當天開。
授權按鈕與門市告示文字等法務定稿。
首頁與個人頁的 20% 定稿等財務。
公益消費參與人次自動化等 POS。在那之前維持 Sheet 手填。
Run for Good 報名、LINE OA 推播等 Phase 3 的決定與預算。

第十五章

執行計畫

開發用的完整版在 repo 裡：docs/phase-2-plan.md，新視窗直接讀它開工。這裡是給大家看的摘要。

開工前先知道的三件事

示範版省略開工前的環境注意事項（金鑰位置、年度清理規則、網域路由）。

開發規則

分支 phase-2，每個工作包做完就 commit、push。
不動正式資料，全部用測試店；新行為都放在 config/features 開關後面，預設關。
bot 先用 no-traffic 的 tagged revision 驗證，確認開關關著才切流量。
暫代文案集中一處並標 TODO(財務)、TODO(法務)，定稿只換一處。
分享與點擊不存 IP 原文；照片紀錄不進 Sanity。

工作包與順序

WP	做什麼	主要檔案	粗估	驗收
WP0	金鑰到位、gcloud 切帳號與專案、開分支、csr-site 工作流加 branch 輸入、建測試店、寄索取清單	keys/、csr-site.yml	0.5–1 天	bot 本機能跑、預覽站能開
WP1	GA4 貼進網站 layout	components.py	0.5 天	即時報表有流量
WP2	授權按鈕與 #公開指令、public 索引與展示圖副本、流水號與短碼、牆面 public_only 開關	main.py、db_service.py、home.js、wall.html	3 天	測試照片變 public，開關關著行為不變
WP3	找照片 API 與 /find/ 頁、50 張 QR	pages/find.py、tools/make_qr.py	2 天	掃 QR 看到當天測試照片
WP4	個人公益參與頁 /p/短碼，含 OG 與 robots 放行	main.py、templates/	2 天	貼進 LINE 有預覽卡
WP5	分享按鈕、短網址 /s/、點擊與新訪客記錄、UTM	main.py、/p 模板	2 天	GA4 看到 utm_content
WP6	分享卡與 IG 圖產圖，存 GCS	services/share_card.py、字型檔	2 天	OG 圖是分享卡
WP7	RTDB rules 收緊、網站改打 bot API	Firebase rules、site.js	1 天	私有節點讀不到，網站照常
WP8	總部 Dashboard v1 與待審核清單	main.py、templates/admin	3 天	總部從網頁設 public
WP9	消費者下架表單與群組通報	pages/takedown.py、main.py	1 天	群組收到通知
WP10	Buy for Good 專區、Run for Good 頁、首頁改版，可平行	pages/future.py、pages/run.py	3 天	預覽站看得到

里程碑

M1
WP0 到 WP3，約 7 個工作天
開關關著上線，GA4 開始累積，找照片與 QR 用測試店驗證。
M2
WP4 到 WP6，累計約 13 天
個人頁、分享、追蹤、分享卡在 bot.example.com 可用。
M3
WP7 到 WP9，累計約 18 天
安全、後台、下架。開關何時真正打開，看第十三章那六項何時到位。
M4
WP10 平行進行
專區與首頁改版，等行銷定稿換文字。

讓每一位參與公益的消費者，都有機會成為下一位消費者認識晴光的起點。