uncle6me-web
f87d0e92f4
leo 更新 leo21c 時撞到（他問「部分失敗？」）： ✗ D1 migration: 部署物缺 kbdb/migrations/0005_credential_template.sql ✗ D1 migration: 部署物缺 kbdb/migrations/0006_drop_credentials_table.sql （四顆 worker cypher/registry/kbdb/mcp 全部 ✓，失敗的只有這兩個檔） 根因不是誰忘了推：.gitignore:53 的 `*.sql` 是為了擋 D1 匯出備份（整庫全量＝機敏）， 但它連 migration 一起吃掉。0001-0004 還在，只因為它們在該規則之前就 commit 了 （gitignore 不影響已追蹤檔案）⇒ 0005/0006 從產生那天起就不在任何 clone 裡。 ⇒ 這不是 leo 一台的事：更新指令從 Gitea 抓 main，那兩個檔不在那裡 ⇒ **任何人裝／更新都會收到同一組失敗**，包含全新安裝。 修法照 rules/05-deploy-convention.md「WASM 來源」段已有的慣例 （`.component-builds/**/component.wasm` 就是用否定規則放行的）： !kbdb/migrations/*.sql 範圍實測（沒開太大）： kbdb/migrations/0005、0006 → 放行 backup-2026.sql / kbdb/backup-x.sql / dump.sql / cypher-executor/export.sql → 仍被擋 進版控前確認過無機敏值：grep 命中的 token/secret/api_key 全是欄位名 （api_key、secret_ref）與註解；無 >=20 位英數的疑似真值。 殘項：leo21c 實查 templates 9 個、credential 不在其中 ⇒ 0005 從未套用， 那台仍停在 D38 之前（credentials 走 0002 的獨立表）。要補套需另跑一次更新。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
48 lines
3.0 KiB
SQL
48 lines
3.0 KiB
SQL
-- 退役 credentials 表（D38 圍牆修復，總管交辦，2026-08-07）
|
||
-- SDD：無專屬 SDD（D38 事故修復任務，見 system-dev/wiki/decisions-summary.md D38 段）。
|
||
--
|
||
-- 這是本次唯一真的需要動表結構的一支 migration，理由（不是繞過鐵律，是鐵律要求的收尾）：
|
||
-- D38 要求 KBDB 回到「只有三張核心表」的狀態。0002_credentials.sql 當初在 KBDB 裡多開了
|
||
-- 一張獨立表，是已知違規（kbdb-usage skill 明文列為反例）。要把違規清乾淨，唯一辦法就是
|
||
-- 真的把那張表拆掉——拆表本身不能只用 API 做（API 不提供「拆表」這種牆內維運操作，
|
||
-- 也不該提供），所以下面兩句 SQL 標 kbdb-sql-ok：這不是繞過圍牆去存取資料，是圍牆施工
|
||
-- 本身（kbdb/migrations/ 就是牆內，本檔存在的唯一目的就是讓舊表退場）。
|
||
--
|
||
-- 冪等設計（deploy.ts 每次部署都會重跑這支檔案，沒有 migration 追蹤表）：
|
||
-- 1. 先補一份空表存在保底——self-hosted 各實例套用進度不一，有些從沒跑過 0002（表從不
|
||
-- 存在）、有些已經跑過本檔一次（表已被拆）。沒有這一步，下面的搬資料/退場語句會因表
|
||
-- 不存在直接整支失敗（D1 對不存在的表沒有條件式跳過語法）。
|
||
-- 2. 把舊表裡「entries 還沒有對應列」的 row 搬進 entries（entry_type='credential'，
|
||
-- page_name=name 冪等鍵，owner_id=api_key，其餘欄位打包進 metadata_json，欄位對應
|
||
-- 0005_credential_template.sql 定義的 slots）。NOT EXISTS 判斷防止重跑造成重複列。
|
||
-- 3. 搬完資料後表就沒有存在的理由，最後一步讓它退場。下次部署若又被步驟 1 重新墊一份
|
||
-- 空殼，也只是空表、立刻搬 0 筆、立刻退場，不影響任何人（真資料只會被搬一次，因為
|
||
-- 步驟 2 的判斷是看 entries 裡有沒有，不是看這是不是第一次跑）。
|
||
CREATE TABLE IF NOT EXISTS credentials ( -- kbdb-sql-ok: 表退場施工步驟①保底存在，非資料存取違規，理由見檔頭
|
||
api_key TEXT NOT NULL,
|
||
name TEXT NOT NULL,
|
||
service TEXT,
|
||
sensitivity TEXT NOT NULL DEFAULT 'standard',
|
||
secret_ref TEXT NOT NULL,
|
||
created_at INTEGER NOT NULL,
|
||
last_used_at INTEGER,
|
||
PRIMARY KEY (api_key, name)
|
||
);
|
||
|
||
INSERT INTO entries (id, entry_type, owner_id, page_name, metadata_json, created_at, updated_at)
|
||
SELECT
|
||
'e_cred_' || lower(hex(randomblob(8))),
|
||
'credential',
|
||
c.api_key,
|
||
c.name,
|
||
json_object('service', c.service, 'sensitivity', c.sensitivity, 'secret_ref', c.secret_ref, 'last_used_at', c.last_used_at),
|
||
c.created_at,
|
||
unixepoch()
|
||
FROM credentials c
|
||
WHERE NOT EXISTS (
|
||
SELECT 1 FROM entries e
|
||
WHERE e.entry_type = 'credential' AND e.owner_id = c.api_key AND e.page_name = c.name
|
||
);
|
||
|
||
DROP TABLE IF EXISTS credentials; -- kbdb-sql-ok: 表退場施工步驟③讓舊表退場，非資料存取違規，理由見檔頭
|