何時需要你決定

Bridge 不會在開工前透過模型反覆追問。它會檢查工單的格式與必填內容，但不會判斷需求是否足夠清楚。writer 的工作依據與 reviewer 的驗收依據都來自工單，因此需求、限制與尚未決定的事都應寫在裡面。以下說明三種需要你處理或確認的情況。

一、開卡前：工單還不能開工

start 用程式把工單當成一張表單來讀，缺少必要內容時，就在顯示卡片前停下，逐項指出問題與行號：

• requested_work（或 run_plan）底下沒有內容，也就是沒有要做的事；
• 沒有驗收清單，或清單裡有一行不是清單項目（「一、」「（1）」在 Markdown 裡不算清單）；
• open_questions 底下還留著問題。每一行都是你還沒回答的問題；把答案寫進工單，再刪掉那一行，或只留 無。

如果你刪掉了必填區塊的標記，它會把標記和標題補回檔案最後面，你寫過的行一個字都不改。補好之後照它印出的指令再 start 一次。這一步不花任何 token。

拿不定主意的地方，就寫進 open_questions：start 會停下來等你回答，總比讓 writer 替你決定好。

二、卡片：你授權的是哪一份內容

卡片列出封存的工單原文、合約 SHA-256、範圍、預算與角色。你說「好」，授權的就是這張卡；之後改了工單，要重新 start 才會採用新內容。代理只能把卡片原文給你看、等你說好，不能替你回答。

三、做工途中：writer 停下來

writer 做工時不會中途停下來等你回答。writer 判斷需要你決定、沒做完就停，或 reviewer 判定要停下（需要你做決定、改動超出授權範圍、牽涉發布動作）時，整次工作就停下，結果檔的標題是「要你決定」，「為什麼」段寫出 writer 的問題、它自己的說法或 reviewer 停下的原因，「下一步」請你把答案寫進工單再 start。輪數用完還沒修好時也會停下，標題是「需修正」。

你寫的東西會怎麼被用

每個區塊照原文抄進合約，驗收清單的每一項就是一個條件。每次 writer 做完，Bridge 自己跑專案的測試，reviewer 對照成果逐條判定；結果檔把每一條標成「已證實」「不成立」或「未知」。從程式碼或測試都看不出來的條件，做得再好也只會是「未知」。

所以每一條驗收，都要寫成 reviewer 在程式碼、測試或程式的行為裡看得到的事。

同一張工單的三種寫法

下面三張工單要的是同一個改動，三張都過得了表單檢查；差別在 writer 要猜多少、reviewer 能判多少。

簡略描述

# 同步時間

<!-- bridge:requested_work -->
在儀表板上找個地方顯示上次同步的時間。

<!-- bridge:acceptance -->
- 看得到。

位置、文字與格式都留給 writer 決定，reviewer 能確認的也只有是否顯示了時間。適合快速試做，但若對上線成果有明確期待，還需要補充條件。

從使用情境描述

# 顯示資料最後同步的時間

<!-- bridge:context -->
客服一直被問儀表板上的數字是不是最新的。

<!-- bridge:requested_work -->
在儀表板頂部顯示最後一次成功同步的時間，用使用者自己的時區。

<!-- bridge:acceptance -->
- 儀表板載入後，頂部顯示「最後同步」加上日期和時間。
- 從來沒同步過時，顯示「尚未同步」，不是空白。
- 時間用瀏覽器的時區。

不必寫檔名或程式碼，writer 會自行尋找適合的位置。每一條都有 reviewer 能從程式碼或測試核對的行為，也涵蓋了從未同步的情況，讓預期成果更明確。

指定程式位置

# DashboardHeader：顯示 lastSyncedAt

<!-- bridge:requested_work -->
在 `DashboardHeader.vue` 讀 `GET /api/sync/status` 回傳的 `lastSyncedAt`，用
`src/utils/time.ts` 的 `formatLocalTime()` 顯示。

<!-- bridge:scope_notes.include -->
- src/components/DashboardHeader.vue
- src/utils/time.ts

<!-- bridge:acceptance -->
- 有 `lastSyncedAt` 時，顯示「最後同步」加上 `formatLocalTime()` 的輸出。
- `lastSyncedAt` 為 `null` 時，顯示「尚未同步」。
- `npm test` 通過。

<!-- bridge:open_questions -->
無

檔案和函式都點名了，writer 會從那裡開始；範圍註記說明改動該落在哪裡。熟悉程式碼時用這種；只知道使用者該看到什麼時，白話版就夠了。

不管哪種寫法都有幫助的事

• 一張工單聚焦一件事。互不相關的改動分開寫，才能分別確認成果。
• 寫出你在意的邊界情況（空的、沒有、出錯、第二次）。工單沒寫清楚的情況，reviewer 就缺少明確的判定依據。
• 不能動的東西寫在 scope_notes.must_keep，已經知道的背景寫在 context；它們會抄進合約，writer 會讀到。
• 團隊的慣例、過去的決定、已驗收的範例，把文件路徑寫進 references；它也會抄進合約。

能用的區塊列在第一張工單。