Leo/Arcrun
1
0
Fork 0
Code Issues 49 Pull Requests 5 Actions Packages Projects Releases Wiki Activity

我的工作流和 recipe 是我的資產，卻放在一個隨時會被換掉的地方 #98

New Issue
Open
opened 2026-08-12 04:10:03 +00:00 by Leo · 1 comment
Leo commented 2026-08-12 04:10:03 +00:00
Owner
Copy Link
Copy Source

leo 2026-08-12：「我們講過 KV 只放暫存會揮發的東西，現在這些是嗎？」
「但 recipe 不是暫存會揮發，它是客戶的資產，為什麼放在 KV？」

逐顆對照（leo21c 實查，2026-08-12）

KV 內容 幾把 key 是暫存嗎
sessions_kv 登入 session 7 ✅ 是
exec_context 執行中的上下文 73 ✅ 是
oauth_kv OAuth 交換中的狀態 1 ✅ 是
webhooks 使用者的工作流定義 9 ❌ 客戶的資產
recipes recipe 定義＋索引 80 ❌ 客戶的資產
submissions_kv 零件投稿 2 ❌ 不是暫存
users_kv / credentials_kv / analytics_kv 使用者／憑證／統計 0 ❌ 不是暫存（目前空）

⇒ 9 顆裡只有 3 顆真的是暫存。 其餘放的是「弄丟了使用者就少了東西」的資料。

今天這件事就是它的代價（Leo/Arcrun#97）

一次更新把 worker 重綁到另一組 KV，使用者當下看到的是：
工作流一支都沒有、portal 登出、80 把 recipe 解不出來。

資料其實沒掉（在原本那幾顆裡），但從使用者的角度那就是「我的東西不見了」。

🔴 如果工作流與 recipe 住在 KBDB，那次重綁不會讓他少任何一支。
會消失的只有 session 與執行上下文——而那兩樣本來就該可以消失。

⇒ 這不只是「放錯地方」的整潔問題：KV 的綁定是可以被一次部署換掉的東西，
把客戶的資產放在那上面，等於把資產綁在一個隨時會被換掉的參照上。

要達成什麼

「弄丟了使用者就少了東西」的資料，一律不放 KV。

判準一句話：這東西掉了，使用者要不要重做一次？ 要 → 它就不是暫存。
（session 掉了＝重登入，不算「重做」；工作流掉了＝要重寫，那就是。）

怎麼驗才算數

  1. 拿一台有工作流與 recipe 的實例，故意把 KV 綁定換成全新的空的，
    使用者的工作流與 recipe 一支都不能少
  2. 同一個動作下，session 與執行上下文消失是可接受的
  3. 貼前後對照的實際輸出

紅線

  • 不准用「把 KV 備份起來」收尾——備份解的是遺失，不解「資產綁在會被換掉的參照上」
  • 資料層規約照既有的走（KBDB 三張表打天下，不加新表；新型別＝seed 一列 template）
  • 搬遷要能對既有實例生效，不是只有新裝的人受惠

相關

Leo/Arcrun#97（今天的意外：更新後 worker 綁到全空的新 KV）｜
Leo/mira#8（安裝器自己從 email 算庫名——同一種「系統替使用者決定資產放哪」）｜
D38（KBDB 三表打天下）｜arcrun-rag CLAUDE.md「長效資料→KBDB、KV 只留暫存」

> leo 2026-08-12：「我們講過 **KV 只放暫存會揮發的東西**，現在這些是嗎？」 > 「但 **recipe 不是暫存會揮發，它是客戶的資產**，為什麼放在 KV？」 ## 逐顆對照（leo21c 實查，2026-08-12） | KV | 內容 | 幾把 key | 是暫存嗎 | |---|---|---|---| | `sessions_kv` | 登入 session | 7 | ✅ 是 | | `exec_context` | 執行中的上下文 | 73 | ✅ 是 | | `oauth_kv` | OAuth 交換中的狀態 | 1 | ✅ 是 | | **`webhooks`** | **使用者的工作流定義** | 9 | ❌ **客戶的資產** | | **`recipes`** | **recipe 定義＋索引** | 80 | ❌ **客戶的資產** | | **`submissions_kv`** | 零件投稿 | 2 | ❌ 不是暫存 | | `users_kv` / `credentials_kv` / `analytics_kv` | 使用者／憑證／統計 | 0 | ❌ 不是暫存（目前空） | ⇒ **9 顆裡只有 3 顆真的是暫存。** 其餘放的是「弄丟了使用者就少了東西」的資料。 ## 今天這件事就是它的代價（`Leo/Arcrun#97`） 一次更新把 worker 重綁到另一組 KV，使用者當下看到的是： **工作流一支都沒有、portal 登出、80 把 recipe 解不出來。** 資料其實沒掉（在原本那幾顆裡），但**從使用者的角度那就是「我的東西不見了」**。 🔴 **如果工作流與 recipe 住在 KBDB，那次重綁不會讓他少任何一支。** 會消失的只有 session 與執行上下文——而那兩樣本來就該可以消失。 ⇒ 這不只是「放錯地方」的整潔問題：**KV 的綁定是可以被一次部署換掉的東西， 把客戶的資產放在那上面，等於把資產綁在一個隨時會被換掉的參照上。** ## 要達成什麼 **「弄丟了使用者就少了東西」的資料，一律不放 KV。** 判準一句話：**這東西掉了，使用者要不要重做一次？** 要 → 它就不是暫存。 （session 掉了＝重登入，不算「重做」；工作流掉了＝要重寫，那就是。） ## 怎麼驗才算數 1. 拿一台有工作流與 recipe 的實例，**故意把 KV 綁定換成全新的空的**， 使用者的工作流與 recipe **一支都不能少** 2. 同一個動作下，session 與執行上下文消失是**可接受**的 3. 貼前後對照的實際輸出 ## 紅線 - 不准用「把 KV 備份起來」收尾——備份解的是遺失，不解「資產綁在會被換掉的參照上」 - 資料層規約照既有的走（KBDB 三張表打天下，不加新表；新型別＝seed 一列 template） - 搬遷要能對**既有實例**生效，不是只有新裝的人受惠 ## 相關 `Leo/Arcrun#97`（今天的意外：更新後 worker 綁到全空的新 KV）｜ `Leo/mira#8`（安裝器自己從 email 算庫名——同一種「系統替使用者決定資產放哪」）｜ D38（KBDB 三表打天下）｜arcrun-rag CLAUDE.md「長效資料→KBDB、KV 只留暫存」
Leo commented 2026-08-12 04:11:38 +00:00
Author
Owner
Copy Link
Copy Source

這張其實是在重講 Leo/Arcrun#16 與 #17

開完才查到：2026-07 就有禁令、也有這兩張交辦票，至今 open。
本張不另立戰場——今天的證據已經掛回那兩張，請以它們為主。

保留本張的唯一理由：它記著 leo 今天給的判準，比原本的政策措辭好用——
「這東西掉了，使用者要不要重做一次？」要 → 它就不是暫存。

## 這張其實是在重講 `Leo/Arcrun#16` 與 `#17` 開完才查到：2026-07 就有禁令、也有這兩張交辦票，至今 open。 **本張不另立戰場**——今天的證據已經掛回那兩張，請以它們為主。 保留本張的唯一理由：它記著 leo 今天給的判準，比原本的政策措辭好用—— **「這東西掉了，使用者要不要重做一次？」要 → 它就不是暫存。**
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
p
high
高——擋住交付或有時間壓力
p
low
低——想做，但晚一點沒關係
s
backlog
驗過了、確定要做，但還沒排進任何 sprint（wishlist／功能需求／待規劃）
s
doing
進行中——現在有人在做
s
pending
卡住——等外部/等人，不是沒人做
s
stage
已推上 stage，等 leo 去 youlin 的 stage 環境驗收（出貨流程第⑤步）
s
todo
待辦——已進池子，還沒開工
s
triage
新進來的，還沒驗傷——還沒決定要不要做
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
oscar Leo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Leo/Arcrun#98
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?