待辦

VIVIAN'S NOTEBOOK · 2026

2026.06.13 · SAT

LAST BUILD 21:41

TODAY 27

件可以推進

32進行中 · 5等外部 · 40天 / 設計完整的「年鑑訂購名單申請雲端審核流程」

檢視

進行中

設計完整的「年鑑訂購名單申請雲端審核流程」

● ● 40 天

最新狀態

[from 2026-05-04 daily log session 3] 卡 5 個未答決策點(動工前要先回): 1. 觸發頻率:月/週 batch vs 一句話觸發 2. 輸出去向:自動補回試算表 / 純 CSV / 三桶分開 3. 比對 key 容錯:編號筆誤(如沈玉萍 1002164 vs 10002164)、公司名第二 key 4. 檔案類型分桶:年鑑 PDF vs 工地外觀平面圖 5. 要不要納入歷史紀錄避免重複開通可樂建議第一版最小可動方案(等決策回完):`scripts/compare_gmail.py`,先輸出 `comparison.csv` 三桶觀察一兩批,不自動寫試算表(沿用 `feedback_minimum_patch_over_framework.md`)。對應 project:`100_Todo/projects/W_年鑑存取權審核對比/`(merge 流程已通,Gmail 比對是這條 todo 的範圍)。

來源

5/4 手工跑了一輪(Gmail 抓 4/15+ 來信 22 筆 → 補進雲端圖庫名單 B338 起)後,西西說現在處理方式不夠正確,要設計常態化流程。流程會持續一整年、頻率不固定、有信就處理。任務線卡在 5 個我問了她還沒回答的關鍵決策點,確認方向才能動工。 [卡點 / 等西西回] 5 個關鍵決策: 1. 頻率與觸發 — 月一次 batch?週一次?還是『Gmail 比對跑一下』一句話觸發? 2. 輸出去向 — (a) 自動補進雲端圖庫名單試算表 / (b) 產 CSV 在 batches/<日期>/comparison.csv / (c) 三桶分開三份 3. 比對 key 容錯 — 編號筆誤(如沈玉萍 1002164 vs 10002164)要不要模糊比對?公司名要不要當第二 key? 4. 檔案類型 — 來信申請『2025年工地年鑑.pdf』vs『2025年工地外觀與平面圖』要分桶嗎?還是一起算? 5. 要不要納入雲端圖庫名單歷史紀錄 — 避免重複開通已通過的人 [已知資源] - project: 100_Todo/projects/W_年鑑存取權審核對比/(任務 1 出貨清單合併已完成,Gmail 比對是這條 todo) - 左半資料:batches/2026-04-30_首批/merged_寄出名單.csv(132 筆) - 右半資料:Gmail MCP 抓 subject:'有人要求共用' after:YYYY/MM/DD - 5/4 手工結果:100_Todo/artifacts/2026-05-04_雲端圖庫名單填寫/paste_into_B338.tsv(22 筆 unique) [可樂建議的最小可動版] - scripts/compare_gmail.py 參數:起始日期 + 批次資料夾 - 第一版不自動寫試算表,先輸出 CSV 給西西人工驗證 1-2 批

conversation · 2026-05-04 · 2026-05-04.md#待辦

年鑑Gmail存取權審核工作流設計卡點

v3 Phase 1 下一步:social_posts FB 12 個月 backfill + WP/GA4/YT 移植

● ● 2 天

最新狀態

[2026-06-11 立案 — 西西🌸 + cola 拍板] 接 nu6dci(Meta Ads daily incremental 已上雲)後的 Phase 1 下一棒。 [為什麼這條優先級高] - Meta Ads `ad → linked_organic_post_id` 19 筆全 0、`is_dark_post=true` 不是真 dark,是 social_posts 表沒收 2025 年那些被 boost 的 organic FB 貼文(摳摳 §5.29 line 1409 親口) - 沒這個 FK = ROADMAP p4「廣告 vs organic 對比頁」做不出來 - 補完後 Meta Ads 那 19 筆 dark 大部分會回頭變 linked(摳摳已備好邏輯) - WP / GA4 / YT 移植本來就在 Phase 1 原計畫 [給摳摳的下一棒] 1. `ingest_social.py` FB 12 個月 backfill(2025-06-09 → 2026-06-09) 2. 跑完後驗 `meta_ads_entities.linked_organic_post_id` 從 0 變多少 3. WP / GA4 / YT ingestion 移植(需先跟可樂對齊文章型 schema:新表 `articles` or 擴 `social_posts` 加 `media_type='article'`,動 schema 是摳摳權責) 4. 三條都通後 social_posts / WP / GA4 / YT 也加 GitHub Actions daily incremental(可比照 Meta Ads workflow 結構複製到 dashboard-deploy/.github/workflows/) [關連檔] - 三方討論: v3.0/三方討論_社群內容檢視.md §5.32 - ROADMAP: v3.0/ROADMAP.html Phase 1 - 上游 todo(已 completed): todo-2026-06-07-nu6dci [37 個月 Meta Ads backfill] 等 Phase 3 廣告卡 / Tab A UI 拍板後一次撈,不在本 todo 範圍。

來源

西西🌸 19:25 拍板:Meta Ads daily incremental 上雲後的 Phase 1 下一動作 = social_posts FB 12 個月 backfill + WP/GA4/YT 移植。原因:Meta Ads ad→linked_organic_post_id 19 筆全 0、is_dark_post=true 不是真 dark,是 social_posts 表沒收 2025 年那些被 boost 的 organic FB 貼文 → 沒這個 FK = ROADMAP p4「廣告 vs organic 對比頁」做不出來。

conversation · 2026-06-11 ·

W_流量儀表板v3.0ingestionsocial_postsWPGA4YTPhase 1

人力規劃 — 礽瑋(Wayne)2 年期間回顧(爭取加薪)

● ● 0 天

最新狀態

[期間設計 — 主推雙時序] - A. 入職至今 2 年 2 個月(2024-04 → 2026-06):累積貢獻 / 留任價值論述。Wayne 跨越部門沿革、累積部門 know-how 的不可替代性靠這段。HR 簽呈『為什麼是這個幅度』看 A。 - B. 近 12 個月(2025-06 → 2026-06):當下表現 / 現價值論述。最近一年具體成果直接撐起當下 ROI。HR 簽呈『為什麼是現在加』看 B。 [例外] 如果礽瑋中間有調過薪,A 改成『上次調薪至今』更精準(超過上次基準的部分才是論述空間)。 [要先確認 — waiting_for] 1. 礽瑋上次調薪是什麼時候?(沒調過 = A 用全期 2024-04 ~ 2026-06) 2. 西西🌸 心中想爭取的調薪幅度(5% 與 15% 的論述厚度不同) [要做的事] 1. 西西🌸 確認上述兩題後,先拉資料軸: - 部門產出統計(2024-04 ~ 2026-06 整段 + 近 12 個月)— 找他主導 / 主要參與的 project list - 跨部門協作紀錄(部門沿革時期的橋接價值) - YT 兩節目(House 超展開 / 房市讀懂了)他的角色與貢獻(memory project_youtube_shows: Wayne 偶入) - 流量儀表板 / 文章工作流等等他的具體貢獻片段 2. 套 90 天評測模板 — 但骨架要改成『長期回顧版』(不是 90 天的成長型,是 2 年累積型): - 上半:累積貢獻 timeline(A 時序) - 下半:近 12 個月 ROI(B 時序) - 加薪論述段(幅度建議 + 競爭力對標 + 留任風險) 3. 產出格式:正式版簽呈 .docx + 視覺版 .html/.pdf(套今天那組 html-slides-to-pdf 工具) [相關紀錄] - memory work_team_roster:三下屬之一,礽瑋(Wayne) - memory project_youtube_shows:Wayne 偶入 House 超展開 - memory feedback_user_words_verbatim_in_external_docs:對 CEO/上層的請示案要逐字尊重西西🌸 原話,加薪簽呈也適用 [關連 todo] - 模板來源: todo-2026-06-13-2984a4 - 同期: todo-2026-06-13-afab17(展碩)

來源

西西🌸:『礽瑋的話來蠻久了,2024 年 4 月初到職的,你覺得應該拉多少日子回顧?我主要是想幫他爭取加薪。』

conversation · 2026-06-13 ·

W_人力規劃評測礽瑋Wayne加薪留任

K W22 睿泰曜 D7 撈數(預定 6/02)

● 18 天

最新狀態

[路徑] `100_Todo/projects/W_文章社群工作流/projects/20260526_ruitai-yao_K/07_decision_card.md` §11 D7 表格 [撈什麼] 三平台 reach + 內容/商業/品牌風險訊號 [對齊主驗證三條] 1. IG「捷運 50 公尺」→ 收藏率(主驗證 1) 2. Threads「南京東路五段 140-160 萬區間」→ 區位/價格討論(主驗證 2) 3. FB「121 戶小尺度社區」→ 留言 callback(主驗證 3) [D7 撈時要看的對位點 — K v2 設計 vs 新潤 D7 基線] 1. **Threads 互動率** vs 新潤 0.07% 基線(1 回覆 / 1,511 views)— 看串文格式有沒有把互動率拉到 0.5%+ 等級 2. **Threads 回覆質感** — 讀者是真的討論「松山買 2 房 4,000 萬該挑哪帶」,還是業配感負評? 3. **FB 留言數** vs 新潤 0 留言 — 看「拿掉外連 + 加情感呼喚」有沒有救留言率 4. **IG 儲存數** vs 新潤 0(reach 109)— 看「捷運 50 公尺」這個主切口能不能帶起收藏訊號 [早期信號 5/27 西西🌸 偷瞄] Threads D1 已經有回覆(N≥1),vs 新潤 Threads D7 整週才 1 回覆。串文格式 + 開放問句設計可能有效,但 N=1 vs N≥1 都還早,要 D7 確認。 [也順手] post URL 三平台已 5/27 回填(decision card §1 Meta)+ status 已改 🟢 published

來源

K v1 第二篇 W22 睿泰曜發布日 2026-05-26,D7 撈三平台流量寫回 decision card §11

scheduled · 2026-05-26 ·

W_文章社群工作流K睿泰曜流量回灌

流量看板 v3.0:社群內容檢視(文案/圖片檢討頁)

● ● 12 天

最新狀態

[定位] v2.0 檢討內容(選題→餵編輯部);v3.0 社群內容檢視 = 檢討社群文案/圖片(餵小編 + 調 AI 產文提示詞)。回顧找規律,非單篇診斷、非前瞻生成。兩頁放 sidebar 內部使用區。 [範圍 — Phase 1 兩 tab] ・Tab A 發文格式成效(FB 為主):格式(連結/文字/長文/單圖/多圖/影片)× 平均分發力大數字排行,給小編發文當下決策。卡點=現有資料沒 media_type 欄→西西拍板補一支 Graph API attachments.media_type fetch,當「全API化第一塊磚」。・Tab B 文案寫法分析(三平台):AI 打標「語氣+結構」(非題材),對上分發指標找規律,結論回灌 social-post-series 提示詞。・好文案口徑=分享+留言+收藏為主、讚降權(依《住展_演算法導向文案設計.pptx》),各平台各自口徑(FB 觸及/分享/留言・IG 互動率/收藏・Threads 留言/分享)。 [Phase 2] 圖片檢討(需先解圖片打標:AI vision 批次 vs 人工欄位),擱置。 [已完成 2026-06-01] ・Demo 完成:v3.0/demo/demo.html(build_demo.py 從 ~/dashboard SSOT 即時算)。三平台×六維度規律總覽×點 bucket drill-down 名單(文案/讚/留言/分享/瀏覽/原文連結)×期間篩選。西西確認 OK。・三方共編討論檔建立:v3.0/三方討論_社群內容檢視.md(含背景補課/共識/資料現實/cola 觀點/會議記錄模板/決議 log/待辦認領)。 [資料現實 — 親查] per-post 指標不齊(IG 沒 shares、Threads 沒 reach)、文案本機只存 100 字預覽、format 欄哪都沒有→完整資料正解=Graph API,與全API化(todo-001)交會。 [下一步] 擇期拉摳摳三方共編上述 md;摳摳優先實查 FB Graph API 能否整塊取代 Playwright + media_type fetch 做法;三方校準 Tab B 標籤體系;定案後 cola 寫 SPEC_社群內容檢視.md。 [SSOT] ~/dashboard。本 todo 屬 v3.0 兩 workstream 之一,另一條=todo-2026-06-01-001 全API化。 [今日進度 2026-06-02] 三方推進。probe 證實 FB/IG/Threads 完整文案可拿(Tab B 抽樣不再卡 100 字預覽)、media_type 可拿(Tab A 第一塊磚成立)。Supabase schema 草案已含 content_label 四維度結構表(鉤子/語氣/結構/紅線)。cola『標籤校準前置』+『SPEC_社群內容檢視』仍待 schema 建表後動工(西西🌸 要求先 plan 完再動)。詳三方檔 §5.15-5.17。 [Plan 已完工 2026-06-04 cola] 等摳摳改 schema 期間,cola 推完三份規格(C→B→A 順序): ・C 能力底:v3.0/REFERENCE_四平台API能力_2026-06-04.md — 整合 FB/IG/Threads/LINE 四份 probe 結果,一頁總覽 + 各平台詳表 + 不可用清單 + retention 速查 + 對 schema 6 條啟示・B 標籤底:v3.0/SPEC_社群文案標籤體系.md — 四維度 v0 標籤集(鉤子 7 / 語氣 6 / 結構 12 / 紅線 6 option)+ 三方校準流程(50 篇 sample → Jaccard 一致率)+ INSERT SQL 樣板・A 本檔規格:v3.0/SPEC_社群內容檢視.md — Tab A 發文格式成效 + Tab B 文案寫法分析完整規格,含 media_type_norm 跨平台對照、平台口徑鎖死、紅線健診獨立區塊、§7 七條解鎖依賴 checklist → 摳摳改完 schema(cola review §5.17 四點)後,按 A §7 依賴順序動:Tab A 解鎖 = 1+2+6 / Tab B 解鎖 = 全部前置。本 todo 仍 blocked by 001。 → README §「v3.0 進行中」段同步加 Plan 進度三條 ✅。 [解除 blocked 2026-06-07・摳摳] todo-2026-06-01-001 已完成：Supabase myhousing schema 上線，ingestion pipeline 小樣本真寫入與重跑安全均已驗證。Tab A / Tab B 產品規格可交可樂接手檢查資料形狀：讀三方檔 §5.21-5.22、ingestion/README.md、SPEC_SupabaseMyhousingSchema.md §10，再對照 SPEC_社群內容檢視.md §7 依賴 checklist。定時跑不急，等可樂確認產品面與標籤校準後再做 GitHub Actions。 [cola 接手 2026-06-07 凌晨] 西西🌸 01:29 轉達摳摳交棒,對齊 project_codex_handoff_observation 完成交接觀察 review(時點合適 / 話術完整但缺結束語 / 完整度超預期),詳三方檔 §5.23。§7 checklist 已更新:1+6 ✅、7 🟡(6 篇樣本太薄,卡 GitHub Actions 排程才會自動累積)。明早 cola 接手方向(等西西🌸 拍板):① 寫 §7 解鎖路徑圖整合散落資訊、② 寫標籤校準批次 SOP(sample 抽法 + Jaccard 一致率算法 + 版本管理)等資料夠就直接套。要等的:③ coco GitHub Actions 排程(資料累積)、④ coco SPEC_AI_labeling_pipeline.md。本 todo 維持 active 不改 waiting_for。

來源

v3.0 第二條 workstream(有別於全API化 todo-001):新增社群「文案/圖片檢討」分析頁。對位選題分析做回顧找規律,拆兩 tab(發文格式成效 FB + 文案寫法分析三平台),圖片檢討列 Phase 2。已用本機真實資料做出 demo 並經西西確認骨架 OK。

conversation · 2026-06-01 ·

流量儀表板v3.0社群內容檢視文案分析三方共編Codex

6/8 驗收 LINE SSO headless 換發撐不撐得過一週

● ● 12 天

最新狀態

6/8(或之後)自動跑後查 _weekly_auto.log:LINE 有沒有靠 headless SSO 換發成功(無跳重登通知)。撐過一週=天花板拉到約每月手動一次;撐不過=退回每週通知重登(無 regression)。若撐不過,實驗『商用帳號(帳密)登入』是否比 QR 久(yahoo 網域不能用企業 SSO 登入)。

來源

LINE 抓 CSV 的後台 session __Host-ses-manager 只活 ~2 天(6/2 過期),已做 refresh_session_via_sso() headless 自動換發(2026-06-01 模擬實測成功)。6/8 自動跑才會在真實過期情境觸發換發。

conversation · 2026-06-01 ·

流量儀表板LINESSO驗收

人力規劃 — 求才文案設計(行銷企劃 JD 對外吸引版)

● ● 9 天

最新狀態

[關連檔] - spec: 100_Todo/projects/W_人力規劃/docs/2026-06-04-人力規劃請示書.md(第六段招聘畫像) - 摳摳簡報: 100_Todo/projects/W_人力規劃/docs/2026-06-04-平台事業部人力規劃請示簡報.pptx(A/B 路線、90 天標準等) - 摳摳延伸 md: 2026-06-04-行銷企劃招募與 90 天成功標準建議.md [要做的事] 1. CEO 核示後拍板 JD 結構(路線 A 中階成長型 NT$ 45-55K vs 路線 B 雙軌即戰型 NT$ 55-65K,西西🌸 已傾向 A) 2. 寫對外吸引版文案 — 不只條列職責,要對齊住展品牌 + 突出『會用 AI 的人才』訴求(對應西西🌸 KPI 調整方向) 3. 各管道版本適配:104 / LinkedIn / 公司官網 / 內部推薦各有字數限制跟調性 4. 發布前 review(可樂跟 / 或摳摳出版本對比) [風格參考] 避免冷冰冰條列 / 對齊住展媒體品牌 / 突出『AI 協作 + 成長空間』訴求 [相關 todo] 跟『面試題目規劃』同期推進

來源

人力規劃案後續工作 — 把 spec 的 JD + 招聘畫像轉成對外吸引人的求才廣告文案,發布到招聘管道。

conversation · 2026-06-04 ·

W_人力規劃招聘文案JD對外

人力規劃 — 面試題目規劃(行銷企劃職缺)

● ● 9 天

最新狀態

[關連檔] - 摳摳簡報 Slide 8: 30/60/90 成果標準 - 摳摳延伸 md: 2026-06-04-行銷企劃招募與 90 天成功標準建議.md - spec 第六段招聘畫像 [核心題型(2026-06-04 跟可樂討論過的方向)] 1. **現場 AI 解題 + 自評** - 給 candidate 真實小題目(例:用 AI 規劃住展找房上線 IG 貼文) - 給 15 分鐘 + 任何 AI 工具 - 然後請他評估自己剛剛的 AI 輸出:對 / 錯 / 改的理由 - 弱訊號:全盤接受『AI 寫得很好』 - 強訊號:主動指出『這像 ChatGPT 模板』『這數字要 verify』『這語氣不像我們品牌』 2. **『最近一次 AI 答錯』故事題** - 問:你最近一次發現 AI 給你錯答案是什麼時候?怎麼發現的? - 答得出來 = 有質疑 AI 的習慣(西西🌸:AI 世代最有價值的人類能力) 3. **Portfolio 展示** - 請對方提出用 AI 做的東西 — 工作流改善 / app / web / 體驗都可以 - 看『問題 → AI 介入 → 結果』故事完整度 - 弱訊號:『我用 ChatGPT 寫文案』(只是工具) - 強訊號:『發現 IG 觸及掉 → Claude 拆解 → 調整 X → 觸及回升 Y%』(problem-solving) 4. **Ownership 探測題** - 問:你工作中遇到 deadline 緊但東西不夠好的時候會怎麼處理? - 看他會不會主動加班 / 預先告知 / 自我修正,vs 只報「沒做完」 [評分對齊] - 30 天標準:能獨立完成固定工作 - 60 天:主動閉環提改善 - 90 天:證明策略成長潛力 - KPI 不用『錯誤率 / 失誤率』(AI 時代非有效指標),改用上述能力訊號 [相關 todo] 跟『求才文案設計』同期推進

來源

人力規劃案後續工作 — 設計面試題庫驗證『AI 協作 + 成長潛力 + Ownership』,對應摳摳補的 30/60/90 KPI 框架。

conversation · 2026-06-04 ·

W_人力規劃招聘面試AI 協作

流量看板 v3.0:ingestion GitHub Actions 定時跑

● ● 6 天

最新狀態

[前置已完成] - Supabase myhousing schema 已上線:10 tables + 3 views。 - `v3.0/ingestion/ingest_social.py` 已能寫 FB / IG / Threads / LINE 小樣本進 Supabase。 - `first_write_2026-06-07`:4 platforms / 4 accounts / 6 posts / 39 post metrics / 16 account metrics / 4 snapshots,4 筆 ingestion_runs 全 success。 - `rerun_safety_2026-06-07`:重跑不撞 partial unique,posts/metrics 沒重複膨脹。 - 固定允許 prefix 已設定給 `ingest_social.py`,本機驗證不用每次按 yes。 [為什麼先不排程] - 西西🌸 拍板:等可樂確認 Tab A / Tab B 產品面與資料形狀後,最後才定時跑。 - 避免一邊排程一邊改底層資料口徑。 [要做的事] 1. 可樂確認 `SPEC_社群內容檢視.md` §7 依賴 checklist,尤其 Tab A / Tab B 是否吃得到目前 view 欄位。 2. 若欄位/口徑需要微調,先改 schema/view/pipeline。 3. 到 GitHub repo 設定 Secrets:Supabase myhousing URL/key、Meta token、Threads token、LINE token。不可把 secret 寫進 repo 或對話。 4. 新增 GitHub Actions workflow,cron 定時跑 `ingest_social.py --all --post-limit <正式值> --write`。 5. 首輪雲端跑完後查 `ingestion_runs` 與 row count,確認無重複膨脹。 [參考檔] - `100_Todo/projects/W_流量儀表板/v3.0/ingestion/README.md` - `100_Todo/projects/W_流量儀表板/v3.0/三方討論_社群內容檢視.md` §5.21-5.22 - `100_Todo/projects/W_流量儀表板/v3.0/SPEC_SupabaseMyhousingSchema.md` §10

來源

摳摳完成 Supabase myhousing ingestion pipeline 小樣本真寫入與重跑安全驗證；西西🌸 決定先交可樂確認產品面，最後再上 GitHub Actions 定時跑。

conversation · 2026-06-07 ·

流量儀表板v3.0GitHub-ActionsSupabaseingestion全API

人力規劃 — 新行銷企劃 90 天評測表事前設計

● ● 0 天

最新狀態

[切入點] 把剛剛剪輯師那份 `2026-06-13-剪輯師90天評估報告.html/.pdf` 的結構抽出來當 baseline,把行業 / 職能特定指標換成行銷企劃適用的(內容產出量、社群成效、企劃完成率、AI 協作品質、Ownership 訊號),做出可給新人 Day 1 就看到的『3 個月會怎麼被評』預告版。 [要做的事] 1. 抽 editor-90day-review.html 通用骨架 → `template-90day-review.html`(模板,放 W_人力規劃/docs/templates/ 或 scripts/) 2. 套行銷企劃指標:對齊 6/4 摳摳的 30/60/90 KPI 框架 + 西西🌸『AI 協作 / 質疑 AI / Ownership』訊號 3. 設計『事前預告版』vs『實際評測版』兩種輸出 — 招募時給 candidate 看的是事前版(只有指標跟達標標準),3 個月後寫的是實際版(填入數字 + 結論) 4. 試跑:拿 6/4 招募請示書的招聘畫像當輸入,跑出一份 sample candidate 的事前評測表 [副產品] 此模板做出來後,展碩 / 礽瑋的評測 todo(afab17 / 86ac53)直接套用,改指標即可,不用各自重寫骨架。 [關連檔] - 剪輯師 90 天 baseline: 100_Todo/projects/W_人力規劃/docs/2026-06-13-剪輯師90天評估報告.html - HTML→PDF 通用工具: 000_Agent/scripts/html-slides-to-pdf/ - 6/4 摳摳 90 天框架: 100_Todo/projects/W_人力規劃/docs/2026-06-04-行銷企劃招募與90天成功標準建議.md - 6/4 面試題庫: inputs/行銷企劃_面試考題_v1.md [相關 todo] - 求才文案 todo-2026-06-04-9bn8u4(blocked by CEO 核示) - 面試題目 todo-2026-06-04-83olls(blocked by CEO 核示) - 展碩 8 個月回顧 todo-2026-06-13-afab17(下游) - 礽瑋 2 年回顧 todo-2026-06-13-86ac53(下游)

來源

西西🌸:『我要新增一名行銷企劃,我也想事前規劃未來要怎麼剪和這位新人=續任評估。』把剪輯師 90 天評測表反向變成招募工具 — Day 1 預告評測標準,對招募也是賣點。

conversation · 2026-06-13 ·

W_人力規劃招聘評測事前規劃

人力規劃 — 展碩(鬍子編)8 個月能力回顧

● ● 0 天

最新狀態

[期間] 2025-10 中 → 2026-06-13,約 8 個月。轉部門前他原屬其他部門,本次評測範圍**只算轉入平台事業部後**這段。 [要做的事] 1. 套 90 天評測模板(等 2984a4 抽出通用骨架後直接用) 2. 重定指標 — 展碩是小編/文字編輯,不是剪輯。建議軸: - 社群文案產出量(每週 FB/IG/Threads 文章貢獻) - 文案品質(過稿率 / 修改次數 / 觸及貢獻) - 跨部門整合度(轉入後跟原部門的協作摩擦點) - 學習曲線(從『鬍子編原領域』到『住展品牌語氣』的對齊速度) - AI 協作熟練度(對應 K 案 / W 案工作流的使用) 3. 結論用途:看是補強教育、調整任務分配、還是該爭取資源(轉正 / 加薪 / 升等) [要先確認] - 展碩確切到職轉入日(目前用『2025-10 中』粗估,實際幾號要查) - 西西🌸 心中的核心 KPI(2-3 個) [關連] - 模板來源: todo-2026-06-13-2984a4 - 剪輯師 baseline: 100_Todo/projects/W_人力規劃/docs/2026-06-13-剪輯師90天評估報告.html

來源

西西🌸:『展碩是去年 10 月中轉來我的部門的,目前是算 8 個月,所以應該是 8 個月的能力回顧。』他不是『新進到職 3 個月』情境,是『跨部門轉入後的階段性回顧』。

conversation · 2026-06-13 ·

W_人力規劃評測展碩鬍子編

K W21 新潤 D14 撈數(預定 6/02)

● 25 天

最新狀態

[路徑] `100_Todo/projects/W_文章社群工作流/projects/20260519_xinrun-shijie-duxin_K/07_decision_card.md` §11 D14 表格 [同天撈] 6/02 跟睿泰曜 D7 同天撈,做 cross-platform 對比 — 新潤 D7 → D14 衰退率 vs 睿泰曜 D7 起步速度 [D14 重點] D7 三條主驗證全 ❌(IG 收藏 0 / Threads 回覆 1 / FB 留言 0),D14 看有沒有遲滯互動(第二週才被滑到的讀者)。如果還是 0,基本確認新潤這篇對位失敗

來源

K W21 新潤世界都心 D14 撈數

scheduled · 2026-06-02 ·

W_文章社群工作流K新潤世界都心流量回灌

K W21 新潤 D30 撈數 + 學到的事總結(預定 6/18)

● ● 25 天

最新狀態

D30 收尾要做: 1. 填 07_decision_card.md §11 D30 表格 2. 填 §12 是否驗證主驗證 3. 寫 §13 學到的事(K v1 第一篇試跑,這篇 signal 對未來 K 案怎麼修) 4. 決議是否納入 K baseline(對齊 K 真相來源 §13 K baseline 原則)

來源

K W21 新潤世界都心 D30 撈數 + 寫 07_decision_card.md §13 學到的事 + 是否納入 K baseline 決議

scheduled · 2026-06-18 ·

W_文章社群工作流K新潤世界都心流量回灌K_baseline

部署「好好過生活」上稿工具到 tool.myhousing.com.tw/alife

● ● 24 天

最新狀態

[來源] W_past-work/INDEX.md #1,裁定=整合。 [現況] 工具是單檔 myhousing-generatorV6.html(200_Reference/W_past-work/住展上稿工具_好好過生活直式html/),讓編輯把每月 txt+圖片素材一鍵匯出『好好過生活』單元的卡片式滑動 HTML。 [要做的事] 部署到 tool.myhousing.com.tw/alife,對齊現有對外工具棧(Cloudflare Worker + Static Assets,加 path = 加檔案,見 W_對外連結工具棧/HANDOFF.md)。動工前確認:工具是否需先調整、是否要 Access 保護。 [無急迫性] 西西🌸『有打算』推上去,未定時程。

來源

past-work INDEX Phase 2 裁定時,西西🌸 表示打算把 #1『好好過生活』單元上稿工具(myhousing-generatorV6.html)推上對外工具棧 tool.myhousing.com.tw/alife。

conversation · 2026-05-20 ·

W_對外連結工具棧好好過生活past-work整合部署

K W22 睿泰曜 D14 撈數(預定 6/09)

● 18 天

最新狀態

[路徑] `07_decision_card.md` §11 D14 表格 [對照] D7 → D14 訊號變化(衰退率、新留言/分享、有沒有觸發第二波互動)

來源

K v1 第二篇 W22 睿泰曜 D14 撈數寫回 decision card §11

scheduled · 2026-05-26 ·

W_文章社群工作流K睿泰曜流量回灌

K W22 睿泰曜 D30 撈數 + 學到的事總結(預定 6/25)

● ● 18 天

最新狀態

[路徑] `07_decision_card.md` §11 D30 + §12 主驗證結論 + §13 學到的事 [特別關注] - 三條主驗證(IG 收藏 / Threads 討論 / FB 留言)實際結果 - 文案 baseline `*_xixi_final.md` 是否需依 D30 結果調整 - Canva pipeline 5 步 SOP 是否需依 D30 結果微調 [判定] D30 後寫:是否納入 K baseline / 是否需調整 K workflow.md

來源

K v1 第二篇 W22 睿泰曜 D30 終局回灌 + §13 學到的事 + 判定是否納入 K baseline

scheduled · 2026-05-26 ·

W_文章社群工作流K睿泰曜流量回灌終局回灌

三棲治理 C 計畫 — 抽 CORE_RULES L2 業務細則成 skill(漸進式)

● ● 16 天

最新狀態

[脈絡] 2026-05-28 三棲治理整套落地,但 CORE_RULES.md(23KB)內部還是 L1 強規則 + L2 業務細則混排。雷蒙路線是把 L2 抽成 skill,觸發詞才載入。memory project_multi_llm_workflow_governance 跟 CORE_RULES 三層記憶段都已對齊這個哲學,差最後一步把 L2 抽出去。 [候選 skill 清單 — 動工順序] **優先(高頻 / 收益明顯)** 1. **住展寫作 skill**(暫名 myhousing-writing) — medium - 抽 CORE_RULES「住展產出規範」整段(編輯人設 / 寫作絕對禁忌 / 社群禁用語 / 受眾對位) - 觸發詞:寫住展貼文 / 寫住展文章 / 寫住展手冊文案 / 涉及住展品牌的內容 - 跟既有 skill 關係:social-post-series / weekly-management-report / youtube-video-package 等住展 skill 可以「include 住展寫作 skill」當前置,語氣禁忌不再重複寫 - 收益:CORE_RULES 瘦 ~3KB;非住展任務不載入禁忌規則 2. **住展手冊規範 skill**(暫名 myhousing-handbook-html) — low - 抽 CORE_RULES「住展手冊 HTML / CSS 規範」(nb-/rh- 前綴 / max-width:800px / :visited / 真實 h2/h3 / div onclick) - 觸發詞:做住展手冊 / 上 WP 手冊 / 新建案手冊 / 賣屋手冊 / 租屋手冊 - 收益:CORE_RULES 瘦 ~1.5KB;只有做手冊才載入 **次要(低頻 / 已部分散在其他 skill)** 3. **字幕製作規範**(暫名 srt-style-myhousing,或併入 srt-traditionalize) — low - 抽 CORE_RULES「字幕製作規範」(斷句 / 避免單行過長) - 但既有 srt-traditionalize / youtube-video-package 已部分包含,可能直接 link 不抽 - 動工前先讀既有兩個 skill 確認 4. **WP 系統管理觸發**(暫名 wp-ops-trigger) — low - CORE_RULES「WP 系統管理特別說明」(先翻 W_wp-ops/) - 但這段已經是「翻 reference 資料夾」的引導句,不適合 skill 化 - 可能保留在 CORE_RULES 不抽 [不抽的 — L1 鐵則或跨家通用] - API Keys / Canva / Playwright 路徑 / 命名 / 提方案前翻 reference / 破壞性操作 / owner / 自我進化 / 三層記憶 / 草稿輸出 / 協作原則 → 全部留 CORE_RULES(NEVER/ALWAYS 跨家通用) [動工建議] - 先做 1 + 2(高頻 + 獨立 + 工程量低) - 3 + 4 等實際撞到再說(漸進式,別預判) - 每抽一個 skill 完工後 CORE_RULES 對應段改成 link 過去(一行帶過 + skill 名),不刪光留導讀 - 抽 skill 時順手加 owner header(雷蒙路線:skill 是 L2 按需載入) [相關檔案] - CORE_RULES.md(要瘦身) - 既有住展 skill:social-post-series / weekly-management-report / youtube-video-package / srt-traditionalize / K_住展開箱工作流(K 案 skill) - 雷蒙 2-4 三層心智模型參考:200_Reference/A_雷蒙claude迷你課/docs/2-4 AI 分身資料夾結構:雷小蒙拆解.md - skill 規格參考:用 superpowers:writing-skills 或 write-a-skill skill 輔助

來源

三棲治理整套落地後(CORE_RULES + 三家 ai.md + llm-routing + owner header + git clone 雷蒙鏡像),最後一塊是把 CORE_RULES 內混在的 L2 業務細則(只有寫住展內容才用到)抽成 skill,讓 AI 按需載入而不是每次 session 都吃 context。雷蒙課程 2-4 三層心智模型的進階做法。

conversation · 2026-05-28 ·

三棲治理skillCORE_RULES雷蒙路線L2-按需

Codex / Gemini onboarding — 每天動一次累積場域(漸進式,週末前到位)

0/3 ● ● 16 天

步驟 0/3

[做法] 不一定每天,但週末前各家至少跑 3-5 個真實任務。具體 checklist 在: - 000_Agent/onboarding/codex-onboarding.md - 000_Agent/onboarding/gemini-onboarding.md [注意] - Gemini daily quota ~80-100 calls,別跑批量 >50 筆 - Codex 沒 daily quota,可以多用 - 跑出來的內容存 100_Todo/drafts/W_gemini-onboarding/(Gemini)+ ~/.codex/sessions/(Codex 自己) [完工標準] 兩家都跑到 onboarding 文件的「場域準備檢查」段。 [進度] ○Codex 跑 3-5 個真實任務 ○Gemini 跑 3-5 個真實任務(注意 daily quota) ○兩家跑到 onboarding 文件「場域準備檢查」段

來源

consensus-builder 首跑前(6/04 預定)需要 Codex/Gemini 累積自己場域,各家 onboarding checklist 已寫在 000_Agent/onboarding/。

conversation · 2026-05-28 ·

三棲治理onboardingCodexGemini

依三棲分工逐步補各 project 的 HANDOFF.md(漸進式,真要轉手時補)

● ● 16 天

最新狀態

[盤點現況 2026-05-28] **✅ 已有 HANDOFF(對齊範本)** - W_對外連結工具棧 / HANDOFF.md(零情境交接,完整,可當範本) - W_文章社群工作流 / HANDOFF_for_consultation.md(給諮詢 AI 看) **🟡 只有 README,未來可能需要補** - W_流量儀表板(轉手成本高,涉及 GAS/Sheet/cron/多語言;若要轉給 Codex 跑某段 fetcher 需要 HANDOFF) - W_Meta內容盈利評估(評估性質,可能 Codex / Gemini 跑分析較合適) - W_派工簽核系統(線上 GAS web app,類似工具棧需 HANDOFF) - W_小編出任務(WP + Cloudflare Turnstile,線上 service) - W_實價登錄轉檔(週期性轉檔,可樂專屬機制較多 — 不一定需要 HANDOFF) - W_年鑑存取權審核對比(目前可樂跑,SOP 寫在 README 也夠 — 暫不急) [判斷標準] 優先補的 = 「即將轉給 Codex / Gemini 跑」或「涉及線上 service / 多人協作」的;純可樂跑的小工作流 README 就夠,不為了齊整硬補。 [範本參考] 100_Todo/projects/W_對外連結工具棧/HANDOFF.md — 零情境交接哲學,適合線上 service / Cloudflare Workers 類;表格密集、實用主義 [相關] - project_multi_llm_workflow_governance(三棲治理本體) - todo-2026-06-04-001(首次 consensus 對辯) - todo-2026-05-29-001(Codex/Gemini onboarding)

來源

三棲治理 consensus-builder 動工時順手盤點 W_* projects 的 HANDOFF.md 覆蓋狀況。8 個 W_ project 只有 2 個有 HANDOFF(對外連結工具棧 / 文章社群工作流),其他 6 個只有 README。漸進式不一次補完 — 西西🌸 真的要把某 project 轉給 Codex / Gemini 跑時再補對應一份。

conversation · 2026-05-28 ·

三棲治理HANDOFFhandoffproject-doc漸進式

流量儀表板 Documents 舊副本退役成純指標(待自動跑綠燈後)

● ● 12 天

最新狀態

確認 6/1、6/8 自動跑穩定後:把 Documents 的 scripts/ + v2.0/ 退成純指標(或瘦身),只留 README/NEXT/HANDOFF/references/artifacts 當源碼文件真相來源。注意 .env 雙份維護(HOME+Documents,rotate token 兩邊改)。相關 memory:reference_macos_tcc_launchd_documents_blocked / project_traffic_dashboard。

來源

runtime 已搬到 ~/dashboard(避 TCC);Documents 的 W_流量儀表板/scripts+v2.0 變成舊副本,有誤改風險。

conversation · 2026-06-01 ·

流量儀表板搬遷清理technical-debt

loveme 自動整理掛 launchd 排程 + 收掉 tccprobe 探針

● ● 11 天

最新狀態

[現況(2026-06-02 01:20 查證)] loveme 自動整理「沒有」每天跑。・auto_generate.sh 已寫好:設計是掃最近 7 天、把「有 web 進件但 vault 還沒寫日記」的天一次補齊(靠 logged_at 不靠跑的當下,睡眠/關機錯過的下次掀開追補),idempotent 不覆蓋手改過的。・但 launchd 排程「沒掛」→ 一次都沒自動跑過,目前全靠手動 /loveme。 [剩沒做的兩件(對齊 memory project_loveme_auto_schedule_idea)] 1) claude -p headless 實測(確認無人值守生得出日記) 2) launchd 排程掛載(可排西西🌸 習慣時間,如傍晚或睡前掃一次)。 [🚩 順手該清] ~/Library/LaunchAgents/net.kcola.loveme.tccprobe.plist 是 5/31 測 TCC 是否擋 launchd 讀 Documents 的探針,每 60 秒跑 ~/loveme_tcc_probe.sh、一直寫 /tmp/loveme_probe.*.log。測試早有結論(memory:TCC 不擋了),應 launchctl unload + 刪 plist + 清 /tmp log,停掉背景空轉。 [腳本位置] ~/.claude/skills/loveme/auto_generate.sh、fetch_raw.py。

來源

凌晨開 /loveme 時西西🌸 問「自動整理每天什麼時候跑」,查證後發現根本沒在跑 —— auto_generate.sh 腳本備好但 launchd 排程沒掛;LaunchAgents 只剩 5/31 測 TCC 留的 tccprobe 探針還每 60 秒空轉。西西🌸 說明天再處理,要我先記進 dashboard。

conversation · 2026-06-02 ·

loveme擁抱自己launchd排程自動化收尾清理

loveme webapp 閱讀端 v1 實作(spec + plan 已完,等動工)

● ● 10 天

最新狀態

[阿匹版保留] 橫向滑動 tab sticky top + 四段固定區塊(生活/情緒/身體/感受一語)+ 詩意小標題 + blockquote 結尾 [2026 升級三點] 1. 雙層 toggle:[原文] [可樂整理] [雙欄並列] 2. 月/週/年三層 view:預設 7 天 + 本月日曆 31 格 + 年度時光軸 3. 搜尋 + 標籤:supabase full-text search,可樂跑時抽 3-5 tag(地點/重要他人/情緒) [D-1A 完 2026-06-03 23:35] 3 篇歷史 md(5/19 / 5/20 / 5/30)透過 import_legacy.py 入 loveme_processed,source_version=legacy-import@2026-06-03;原檔 archive 到 300_Reflection/C_擁抱自己/_archive/2026-06-03_imported-to-supabase/ 含 README。剩 D-1B(UI 空殼)+ D2~D5(升級三點)留週末。 [2-3 小時工作量] D-1B 開做時直接從 supabase 拉 3 row 驗渲染 [2026-06-04 02:00 brainstorming + spec + plan 完工] • 推翻阿匹版滑塊(電腦版專屬,RWD 不友善) • 新主架構:五頁式底部 nav(卡片/月曆/寫 FAB/靈感預留/我)+ 14-slot Bento explicit grid pattern(西西🌸 Excel 親自排)+ 顏色綁日 random / size 浮動 index%14 循環 • 加 iPhone safe-area 規範段(避免連結收藏看板那種頂部斷層) • spec: docs/2026-06-04-reading-end-ui-design.md(12 段) • plan: docs/2026-06-04-reading-end-implementation-plan.md(15 task,step-by-step + code) • 實作留下次 fresh session,plan self-contained 可直接接

來源

走 3a 後不再有 md 檔,改用 webapp 介面看日記。設計參考 2025 阿匹版 200_Reference/C_past-work/擁抱自己日誌/擁抱自己日誌_滑動頁籤_長頁示意版.html

conversation · 2026-06-03 ·

cc-brainlovemewebappuiphase-1-prep

本機 → cc-brain 自動同步機制評估(Phase 2)

● ● 10 天

最新狀態

[選項] 1. PostToolUse hook 偵測 ~/.claude/.../memory/ 寫入 → 自動 push(最即時) 2. launchd 排程每天 / 每小時跑 sync.sh + commit + push(撞 TCC 讀 Documents,要驗證) 3. 維持手動(預設,可樂語意觸發,維護負擔最低) [現況] 預設 3,觀察哪個方案是必要的(可能不必要) [參考] reference_cloud_hybrid_architecture §3 同步機制

來源

Phase 0 預設手動同步(可樂語意觸發),Phase 1 觀察期跑通後評估要不要自動化

conversation · 2026-06-03 ·

cc-brainautomationphase-2

用阿乃社群研究升級 social-post-series 五版本(加 IG + 全平台 refine)

● ● 9 天

最新狀態

[來源檔案] /Users/vivian-m4air/Documents/CC-Agent/100_Todo/drafts/W_social-posts/2026-06-03_台灣房產社群帳號研究.md(616 行,阿乃 6/3 DeepResearch 產出) [包含什麼] 五張表(IG 圖文 / IG Reels / FB 圖文 / FB Reels / Threads)各 Top 15 帳號 + 第二層 27 則熱門文案全文(9 帳號 × 3 平台)+ 平台架構心法提煉(IG 視覺包裝 / FB 專業深度 / Threads 去精緻化情緒共鳴) [要做的事] 1. 跟可樂討論研究結論 — 哪些 pattern 適合住展品牌、哪些不適合(住展是『媒體』tag 不是『自媒體』犀利觀點型) 2. 從原 27 則範例抽住展可借鑒的句式 / 排版 / hashtag 慣例 3. 升級 social-post-series skill 五版本提示詞包(200_Reference/W_templates/住展-社群文案五版本提示詞包-v5.md)→ v6 包含: • 加 IG 圖文版本(原五版只有 FB×4 + Threads) • 既有 FB / Threads 版本 refine(對齊阿乃研究觀察) • IG hashtag 策略 + 首行 hook 截斷規範 4. 範本沉澱進 200_Reference/W_writing-samples/social/ [西西🌸 視角] 不是『讓阿乃寫文案』(她寫文案放飛已被 P4 否決),是『拿阿乃的研究當素材源,可樂判斷取捨升級規範』 [相關] 真相來源 200_Reference/W_templates/住展-社群文案五版本提示詞包-v5.md;社群文案檢討框架真相源 = `演算法導向文案設計 deck`(memory: reference_algo_copy_design_deck) [合併歷史] 原 todo-2026-05-29-003(2026-05-29 立,『找 IG 範本加入 social-post-series skill』)— 範圍當時只規劃加 IG,今天阿乃研究上桌後擴展到『全平台五版本 refine + 加 IG』,合併到此 todo。

來源

西西🌸 2026-06-03 派阿乃做台灣房產社群帳號 DeepResearch(IG/FB/Threads 三平台 Top 15 + 9 個代表帳號 27 則熱門文案全文)→ 拿來跟可樂討論升級 social-post-series 五版本提示詞包(原 todo-2026-05-29-003『加 IG 範本』合併進此 todo)。

conversation · 2026-06-04 ·

social-post-seriesskillIGFBThreadsW_文章社群工作流

v3 看板新維度 — 接 YouTube Ads API(住展 MyHousing TV 投放成效)

● ● 6 天

最新狀態

[2026-06-08 12:52 降回 P3 — 前提崩了] 早上 12:44 西西🌸 拍板「先動 Google Ads API 申請」,可樂 12:48 起草申請流程(草擬 use case 描述、列三步驟);12:50 西西🌸 補一句『YT 廣告是投放商投的,不是用我們的 ads 帳號』,Google Ads API 申請整個前提崩 — API 只能讀自己帳號,投放商帳號拿不到。住展自有 Ads 帳號存在但已停用,真要用要重新啟用。降 P3 + 留檔不關:這條未來只有兩種狀況會復活 — (a) 住展自己重啟 Ads 投放、(b) 投放商願意給住展 Ads 帳號 read-only invite 或 monthly CSV。兩者目前都不在規劃內。至於昨晚升 P1 依據『YT ADVERTISING = 最高流量源』,釐清後是 YouTube Analytics 的 `insightTrafficSourceType` — 這條觀看數佔比資料**已經透過 yt_probe.py 撈到了**,Phase 1 ingestion 移植時把這欄接進 sheet 即可滿足『看廣告貢獻多少觀看』的需求,不需要 Google Ads API。 [原 P1 依據 — 留檔備未來回看] local_preview YT 流量來源段(`v3.0/local_preview/preview.html`)顯示近 30 天 `insightTrafficSourceType` 中 ADVERTISING = 最高來源(西西🌸 親查確認)。 [背景] v2 / v3 YT organic 走 YouTube Data API + Analytics API(`data_yt.py` / `data_yt_videos.py`);YT 廣告投放成效要另走 Google Ads API(YouTube 是 Google Ads 底下的 channel,沒有獨立『YouTube Ads API』)。 [待先確認] 1. 住展 MyHousing TV 兩個節目(House超展開 / 房市讀懂了)有沒有 YT 廣告投放?(若沒有 / 預算極低 = 這條優先級下修) 2. Google Ads account 屬於誰管?有沒有 manager account? 3. Google Ads API 申請 developer token(等待期 1-2 週) [要做的事] 1. probe Google Ads API:campaign / ad group / video ad 三層 metric,確認 YT 投放可用欄位(impressions / views / view_rate / cost / conversions) 2. 跟 YT organic data 怎麼 join:同一支影片廣告觸發的 views 要不要跟 organic views 分開呈現? 3. schema 補表 + 寫 `ingest_ads_youtube.py` 4. v3 看板加 YT 廣告卡 [關連檔] - v2 YT organic 慣例: memory/reference_yt_analytics_partial_month_workaround.md - v3 schema: 100_Todo/projects/W_流量儀表板/v3.0/SPEC_SupabaseMyhousingSchema.md [相關 todo] 跟 Meta Marketing API 同期推進

來源

同 Meta Marketing API 那條 — 西西🌸 拍板廣告維度是 v3 看板真正欠的方向;YT 廣告(Google Ads / YouTube Ads API)是 v2 / v3 從未接過的維度。

conversation · 2026-06-07 ·

W_流量儀表板v3.0ingestionYouTube廣告新維度

v3 看板補完 — FB Stories / IG Stories endpoint 重測

● ● 6 天

最新狀態

[背景] 6/2 三方 probe session 拍板兩平台 Stories 都待重測: - FB Stories: endpoint HTTP 500(公開 Graph API 不穩,可能 Meta 端問題) - IG Stories: endpoint HTTP 200 但 count=0(當時沒 active story 樣本),insights 待測業務量級: FB_STORY ≠ IG_STORY,FB 月 70-80 篇(2026-04 起),IG 月 5-10 篇(memory/reference_fb_ig_story_volume_distinct)。FB Stories 量更大、優先級稍高。 [要做的事] 1. 重跑 FB Stories probe — 確認 500 是當時 Meta 端短暫問題還是永久不給(若永久不給 → 標 N/A 收編) 2. 重跑 IG Stories probe(這次撈時段內有 active story 的樣本)— 測 insights metric 可用度 3. 通的 metric 補進 `REFERENCE_四平台API能力_2026-06-04.md` 末尾「待補」段 4. 評估納入 v3 ingestion `ingest_social.py`(不大,加 platform=fb/ig 內的 stories branch) [關連檔] - 原始 probe: 100_Todo/projects/W_流量儀表板/v3.0/RESULT_FBGraphAPIProbe_2026-06-02.md / RESULT_IGGraphAPIProbe_2026-06-02.md - API 能力總覽: 100_Todo/projects/W_流量儀表板/v3.0/REFERENCE_四平台API能力_2026-06-04.md(末尾待補段) - 業務量級: memory/reference_fb_ig_story_volume_distinct.md [優先級] P3 — 補完性質,不阻塞 v3 月度/週度看板主線

來源

西西🌸 整理 v3 待補 todo 時把 Stories 列進來 — 6/2 round 1 probe FB Stories 撞 HTTP 500、IG Stories endpoint 通但 0 active sample,當時拍板『先標待查不阻塞主線』,現在主線(organic ingestion)已上線,該回頭重測。

conversation · 2026-06-07 ·

W_流量儀表板v3.0probeStories補完

W_article-social-workflow pipeline 改進點(MVP 第一篇試跑撈到)

● ● 0 天

最新狀態

2026-05-08 第一篇 chuzu-shengshui_W 跑完 Phase 1-5 撈到 3 個改進點,觀察期 2-3 週,等下幾篇 W 跑下來真的成痛點再升 memory: (1) skill 五版本沒 IG 專屬版 — 慣例借用版本一圖卡,但 W 不出圖時 IG 怎麼補?要在 prompts/04_creative_W.md 加「不出圖 + 沒 IG 版」備案文案(例如 IG 借版本一文案 + 主標副標當 caption)。(2) Gemini 補出原文沒有的數字(本案 4.8%)需手動把關 — 這次紅線守住但下次同類情境要 systematize,Phase 5 事實檢查清單加一條「比對 Gemini Phase 2 輸出有無加進原文沒有的數字」。(3) prompts/01_content_brief_W.md URL 抓取從「未支援」改「走 WebFetch」— 本次已修(2026-05-08 親驗住展 WP 不被 Cloudflare 擋)。詳見 100_Todo/projects/W_article-social-workflow/projects/20260508_chuzu-shengshui_W/07_decision_card.md「MVP 第一篇備註」段。

來源

· ·

AI協作工作流改進點W_article-social-workflow

等外部

loveme-nightly GitHub Action workflow(等 6/15 OAuth token)

● ● 10 天等 · 6/15 Anthropic 釋出 CLAUDE_CODE_OAUTH_TOKEN 機制

最新狀態

[路徑] cron 23:50 → GitHub Action runner → checkout vivian108318/cc-brain → claude -p "/loveme" 帶 OAuth token → 整理 supabase loveme_raw 當日進件 → 寫 loveme_processed → webapp 看 [前置依賴] todo-2026-06-03-003(supabase 表 + SKILL 改造)需先完成才能寫 workflow [credit] 月耗估算 $5-10 / $100 credit(loveme 一天一篇 30-50k token,sonnet 4.6) [參考] reference_cloud_hybrid_architecture §4 + §7 Step 2

來源

Phase 1:cc-brain 已上線,等 6/15 後 Anthropic OAuth credit 機制可拿 token,寫 loveme-nightly.yml workflow:cron 23:50 → checkout cc-brain → 跑 claude -p "/loveme" → 寫回 supabase loveme_processed → 跨裝置看 webapp

conversation · 2026-06-03 ·

cc-brainlovemegithub-actionphase-1cloud-hybrid

K 版本第一篇 P5 meta 觀察期(4 個 meta 假設驗收,到 5/24 滿 2 週)

● 31 天等 · 流量資料累積到 2026-05-24(滿 2 週)— D7/D14 流量回灌 + Phase 5 final review 的 4 個 meta 假設驗收

最新狀態

[脈絡] 第一篇 K(helei-tianmu)2026-05-12 實戰首發,Phase 5 final review 留 4 個 meta 假設要實戰驗證(主切口「青埔 6 字頭 vs A20 47 起跳」凹陷區比較是否打動;流量假設 IG 1500-3000 / FB 3000-6000 / Threads 500-1500 範圍是否準;K 結構/W 結構選擇判準準不準;Gemini Search grounding 數字校正紅線守得住嗎)。 [到期動作] 5/24 滿 2 週,讀 D7/D14 數據,寫對照表進 07_decision_card.md「MVP 第一篇備註」段。 [相關 todo] todo-2026-05-09-002(住展開箱第一篇 K)/ todo-2026-05-09-001(MVP 試跑改進點)

來源

5/10 K 版本 4 個 P5 meta 觀察期(到 5/24 滿 2 週)

daily_log · 2026-05-12 · 2026-05-12.md#沿用未動

K住展開箱觀察期P5 meta

Rotate Cloudflare API Token(tools/s-myhousing,2027-04-17 觸發)

● 27 天等 · 等到 2027-04-17(token 2027-05-17 到期前一個月開始 rotate,避免 deploy 突然失效)

最新狀態

**觸發日期**:2027-04-17(token 到期前一個月) **承接**:todo-2026-05-16-001 因 2026-05-17 應急 rotate 提早完成,新 token TTL 1 年。 **SOP**(完整版見 `100_Todo/projects/W_對外連結工具棧/HANDOFF.md §8`「Rotate API token」): 1. Cloudflare 後台 → API 權杖 → 找到當前 token → Roll 2. 複製新 token,離開頁面就看不到 3. 開 `~/Documents/CC-Agent/.env` → 把 `CLOUDFLARE_API_TOKEN=` 換成新值 4. 驗證:`export CLOUDFLARE_API_TOKEN=... && npx wrangler whoami` 應印出公司帳戶名做完 rotate 後新 token 再設 1 年 TTL,順手把這條 todo 完成 + 新增一條 2028-04-17 提醒。

來源

2026-05-17 凌晨應急 rotate 後 token 重新計時 1 年,到期 2027-05-17。承接 todo-2026-05-16-001(已 completed,因應急 rotate 提早觸發)。

conversation · 2026-05-17 ·

W_對外連結工具棧CloudflareToken-rotate排程提醒

dashboard:本月關鍵戰役 mapping 推進(WP↔社群)

● ● 0 天等 · 上游缺發文 SOP — 過去發 FB/IG 貼文時沒在固定欄位記 WP article_id,WP 連結也常放在回覆留言區不是本文,歷史資料根本沒有可 join 的 key。要等編輯部建立發文時的 mapping 規範才能往下做。

最新狀態

設計初衷=WP top 10 為錨,5 平台同步表現的 cross-platform view。 **[2026-05-09 西西決議 block]**:這頁要做必須有 WP↔社群 mapping,但**過去發貼文時根本沒做這些設置**(沒埋 article_id、WP 連結放回覆區),歷史資料補不出來。三條解法都治標(first comment 抓不全 / 標題模糊不準 / 編輯部規範要跨部門推),先擱置。 **重啟條件**:跟編輯部協調建立發文 SOP(每篇 WP 發布時 → 社群貼文固定欄位記 article_id 或 WP URL 放本文),從未來新貼文開始累積 mapping,半年後資料量夠再做這頁。 **歷史路線文件保留**(以下原規劃留檔不刪):path locked: (a) 抓 FB/IG 貼文 first comment 文案(Meta API 給 comments 列表),從 first comment 找 WP URL。撞牆再討論 (b)(標題模糊比對,不準)或 (c)(請編輯部固定欄位記 article_id,跨部門需協調喬慧)。

來源

· ·

dashboard關鍵戰役WP-社群-mappingphase2blocked

dashboard:作者貢獻表加「社群擴散倍率」欄

● ● 0 天等 · blocked by todo-2026-05-07-004(同樣的 WP↔社群 mapping 缺口,等編輯部發文 SOP 建立後才解)

最新狀態

公式:每作者文章被社群推送後的觸及 ÷ WP PV。**前置依賴本月關鍵戰役 mapping**(todo-2026-05-07-004)解決後加。作者貢獻主表已 5/6 完成(todo-2026-05-06-004),這條是 enhancement。 **[2026-05-09 跟 -004 一起 block]**:同樣需要 mapping。

來源

· ·

dashboard作者貢獻enhancementphase2blocked

最近完成 · 14 天內

✓

v3 看板新維度 — 接 Meta Marketing API(FB / IG 廣告投放成效)

2026-06-11

✓

流量看板 v3.0:全 API 化:Supabase myhousing 建表 + ingestion 小樣本寫入

2026-06-07

✓

cc-brain 基建上線(Phase 0 全推完成)

2026-06-03

✓

supabase loveme_processed 表 + SKILL.md 改造寫 JSON(B+C 完)

2026-06-03

✓

小編出任務表單加 CAPTCHA(Cloudflare Turnstile → Forminator)

2026-06-01

✓

驗收流量看板第一次自動排程跑(6/1 07:00)

2026-06-01

✓

daily log 模板分兩段(Facts / Opinions)— consensus 隔離輸入用

2026-05-31

✓

三棲治理 — 跑首次 consensus-builder 對辯(視 Codex/Gemini onboard 進度調整)

2026-05-31