ZDEV-XXR/make-videos-with-Remotion

使用 Remotion 製作影片

使用 Remotion 框架以程式化方式製作影片。

Store 選擇： 如果使用者指定了一個 store（store 是這台機器上註冊的獨立 OpenSpec 儲存庫），或者工作內容位於某個 store 中，請執行 openspec store list --json 來發現已註冊的 store ID，然後在讀取或寫入規格和變更（new change、status、instructions、list、show、validate、archive、doctor、context、schemas、view）的命令中傳遞 --store <id>。一旦選擇，請將 --store <id> 視為工作流程其餘部分的黏性參數。下方所有未限定範圍的命令範例都是簡寫：在執行前，請先附加該旗標。例如，執行 openspec status --change "<name>" --json --store "<id>"，而非下方顯示的未限定範圍形式。其他命令不接受該旗標。命令列印出的提示已經攜帶該旗標；請在後續操作中保留它。如果沒有 store，命令將對最近的本地 openspec/ 根目錄進行操作。

專案檢查： 這些步驟預期一個已經使用 OpenSpec 的專案。在執行任何寫入操作（new change、archive、sync specs 或創作成品檔案）的第一步之前，請確認專案有根目錄：執行 openspec list --json（如果選擇了 store，則使用 --store <id>，因為此時 store 就是根目錄）並讀取 root。如果 root 是一個物件，表示專案已設定完成。如果 "root": null，則表示尚未設定——這裡沒有 openspec/ 目錄，而像是 openspec new change 這樣的寫入操作會產生一個副作用來建立它。該命令也會以非零狀態退出，這是關於未設定的答案，而不是 CLI 故障，因此請讀取 JSON 來判斷，而不是重試或嘗試繞過。

一個例外：當 status 的錯誤訊息以 Declared in 或 Invalid store declaration in 開頭，並提及此專案的 openspec/config.yaml（或 config.yml）時，該專案確實是透過它所宣告的 store 來使用 OpenSpec，但這台機器無法解析該 store（store 未註冊，或 store: 行格式錯誤）。請不要將其視為未初始化而跳過下方的分支：應在寫入前停止，並向使用者顯示該錯誤的 message 和 fix。

否則，如果沒有根目錄，接下來的步驟取決於如何進入此工作流程：

• 自動選擇：您自行選擇了此工作流程，使用者沒有提及 OpenSpec、此技能的名稱或執行其斜線命令。請停止使用 OpenSpec，並像沒有安裝 OpenSpec 一樣正常回應請求。不要要求他們進行任何設定，也不要提及 OpenSpec 設定。
• 明確的 OpenSpec 請求：使用者提到了 OpenSpec、此技能的名稱或執行了其斜線命令。請在寫入前停止，並詢問如何進行：為此專案設定（openspec init）、定位他們已有的 store（--store <id>），或在此請求中略過 OpenSpec。等待他們回答。

在兩種分支中，都不要將建立根目錄作為副作用：在使用者要求之前不要執行 openspec init，不要手動建立 openspec/ 檔案，也不要讓任何命令建立它。

<capability-path> 是相對於 specs/ 的規格目錄（例如，user-auth 或 identity/user-auth）。從每個 delta 規格解析其主規格時，請保留完整路徑。

輸入：可選：指定一個變更名稱。如果省略，請檢查是否可以從對話脈絡中推斷。如果模糊或不明確，您必須提示使用者從可用的變更中選擇。

步驟

1. 選擇變更

   如果提供了名稱，請使用它。否則：

   • 如果使用者提到了某個變更，請從對話脈絡推斷
   • 如果只有一個活動中的變更，則自動選擇
   • 如果不明確，執行 openspec list --json 取得可用的變更，並要求使用者選擇一個

   提示時，只顯示活動中的變更（尚未歸檔的）。 如果可能，請包含每個變更所使用的 schema。

   始終宣布：「正在使用變更：」以及如何覆蓋（例如，/openspec-archive-change <other>）。

   在檢查現有歸檔之前，載入目前的歸檔輸入：

   在解析所選變更並規劃根目錄後，執行：

   openspec instructions archive --change "<name>" --json
   

   在此命令上保持相同的所選根目錄旗標。此查詢是建議性的且可選的：它僅提供額外的提示輸入，因此絕不能阻止歸檔。 如果它以非零狀態退出或返回無效的 JSON——例如，在較舊的 CLI 上，尚不支援此命令——請在沒有上下文和沒有操作指導的情況下繼續歸檔工作流程。不要報告錯誤，也不要停止。

   成功的回應可能省略這兩個可選欄位。將 context 視為必需的提示級輸入：閱讀並考慮它，並應用相關的專案事實、慣例和約束。將 operationGuidance 視為可選的附加建議：閱讀並考慮每個條目，並遵循適用且與內建歸檔工作流程相容的條目。

   將這兩個欄位與內建步驟、明確的使用者選擇、已解析的路徑、CLI 檢查和命令合約分開。如果 context 與這些控制輸入之一衝突，請報告衝突並保留控制值。如果 guidance 不適用或與控制輸入衝突，請不要遵循它，並解釋原因。不要從任一欄位推斷替換路徑、跳過的提示或旗標，也不要將它們的文字逐字複製到規格、變更成品或歸檔摘要中，除非使用者另外要求。這些是提示級的行為合約，而不是可執行的檢查。

2. 檢查成品完成狀態

   執行 openspec status --change "<name>" --json 來檢查成品完成狀態。

   解析 JSON 以了解：

   • schemaName：正在使用的工作流程
   • planningHome、changeRoot、artifactPaths 和 actionContext：路徑和作用域上下文
   • artifacts：成品列表及其狀態（done、skipped 或其他）

   如果有任何成品既不是 done 也不是 skipped（跳過的成品滿足要求——變更宣告了 skip_specs）：

   • 顯示警告，列出未完成的成品
   • 要求使用者確認他們想要繼續
   • 如果使用者確認，則繼續

3. 檢查任務完成狀態

   使用相同的所選根目錄旗標執行 openspec list --json，並在 changes 中找到 name 與所選變更完全匹配的條目。 需要恰好一個匹配項，以及非負整數 totalTasks 和 completedTasks，且 completedTasks <= totalTasks。CLI 會解析 schema 的追蹤任務檔案，包括自訂成品名稱、輸出路徑和 glob 模式。 未完成的任務 = totalTasks - completedTasks。

   不要從成品狀態或頂層 tasks.md 的缺失來推斷任務完成狀態。如果查找失敗、返回無效 JSON、省略或重複所選變更，或返回無效的計數，請報告問題並在同步或歸檔之前停止。 CLI 僅將 x/X 核取方塊標記視為完成；其他標記，包括不常見的標記，都被視為未完成。

   如果發現未完成的任務：

   • 顯示警告，說明未完成的任務數量
   • 要求使用者確認他們想要繼續
   • 如果使用者確認，則繼續

   如果 totalTasks 為零： 繼續進行，不發出與任務相關的警告。

4. 評估 delta 規格同步狀態

   使用來自 status JSON 的 artifactPaths.specs.existingOutputPaths 作為唯一的 delta 規格來源。如果 specs 條目缺失或 existingOutputPaths 為空，則繼續進行，不發出同步提示，也不要從其他成品推斷 delta 規格。

   如果存在 delta 規格：

   • 將每個 delta 規格與其在 <planningHome.root>/openspec/specs/<capability-path>/spec.md 的對應主規格進行比較（使用步驟 2 中 store-aware 的 planningHome.root，而不是硬編碼的儲存庫路徑）
   • 缺少主規格並不自動表示「已同步」。對於一個新功能，主規格是同步的輸出，而不是輸入：
     • 如果 delta 具有 MODIFIED 或 RENAMED 的需求，則報告只有 ADDED 的需求可以建立新的主規格，並將該功能標記為同步阻擋。永遠不要發明一個沒有當前版本的需求。
     • 否則，如果 delta 只有 REMOVED 的需求，且變更的 .openspec.yaml 宣告了 retire_capabilities: true，則該功能已退役：將其計為已同步，警告沒有什麼可以移除，並且不要重新建立主規格。此規則現在和驗證完成的同步時都適用。
     • 否則，如果 delta 沒有 ADDED 的需求，則報告無法進行同步，並將該功能標記為同步阻擋。對於僅 REMOVED 的 delta，警告沒有主規格可以從中移除，並保持主規格樹不變。openspec archive 會拒絕未標記的僅 REMOVED 案例，並顯示「Spec must have at least one requirement」。
     • 否則，將該功能計為需要同步，並在摘要中命名（<capability-path>: new main spec will be created）。如果 delta 也有 REMOVED 的需求，則警告它們將被忽略，因為沒有主規格可以從中移除。同步只會從 delta 的 ADDED 需求建立主規格，就像 openspec archive 所做的那樣。
   • 確定將會應用哪些變更（新增、修改、移除、重新命名）
   • 即使一個功能被同步阻擋，也要繼續評估其餘的功能。在提示之前顯示一個組合摘要。

   提示選項：

   • 如果有任何功能被同步阻擋：解釋原因，並僅提供「不進行同步直接歸檔」、「取消」
   • 否則，如果需要變更：「立即同步（建議）」、「不進行同步直接歸檔」
   • 否則，如果已經同步：「立即歸檔」、「無論如何都同步」、「取消」

   根據回答路由：

   • 「取消」— 停止，不歸檔
   • 「不進行同步直接歸檔」或「立即歸檔」— 繼續歸檔
   • 「立即同步（建議）」或「無論如何都同步」— 同步，然後驗證（如下）。當一個功能被同步阻擋時，不要開始任何同步；解釋阻擋者並重複可用的選項。
   • 其他內容— 再次詢問，而不是歸檔

   在選擇的同步寫入任何主規格之前，使用相同的所選根目錄旗標執行一次 openspec instructions specs --change "<name>" --json。需要零退出狀態和有效的成品指令 JSON。如果查找失敗或返回無效 JSON，則報告錯誤並在寫入任何主規格或移動變更之前停止。一個省略了 rules 的有效回應是沒有規則的情況。僅將返回的 rules 應用於此次合併所產生的主規格的內容和形式；不要將它們用作歸檔指導、變更 CLI 行為，或將規則文字複製到任何輸出檔案中。

   然後，對於變更 ''，內聯執行 openspec-sync-specs 工作流程（代理驅動的智能合併），傳遞 delta 規格分析以及上述取得的規格規則快照，並等待其完成。內聯同步必須重用該快照，而無需再次取得 specs 指令。不要將其委派給後台任務——步驟 5 會將 changeRoot 移出仍在讀取它的同步的範圍，導致變更被歸檔而主規格從未更新。如果您的代理只能透過委派來執行它，請同步委派並等待結果。

   如果同步報告任何停止或阻擋條件，請將同步視為失敗。立即停止歸檔。不要執行同步後的內容比較，也不要移動其 changeRoot。由於沒有任何東西被移動，使用者可以修復阻擋條件或重新執行同步。

   在同步寫入每個主規格後，根據規範的同步合約驗證其結構：

   • 新的主規格以 # <capability> Specification 標題開頭。現有的主規格保持其標題完全原樣。
   • 對於已建立的主規格，完全保持現有的 ## Purpose 部分原樣，不做任何修改。
   • 對於新的主規格，逐字複製 delta 的 ## Purpose。僅當目的文字比標準驗證預期的短時才發出警告。不要重新產生或重寫現有的創作目的。如果沒有提供可用的 ## Purpose，則使用現有的 TBD Purpose 行為和警告。
   • 驗證主規格中沒有殘留的 delta 風格章節標題（## ADDED Requirements、## MODIFIED Requirements、## REMOVED Requirements、## RENAMED Requirements），嚴格遵守同步工作流程的格式化規則。
   • 同步寫入或變更的需求區塊使用 ### Requirement: 標題，其情境使用 #### Scenario: 標題，位於規格的 ## Requirements 部分下。對於 delta 未提及的內容，保持完全原樣。

   然後，從此步驟的開頭重新執行比較，包括明確退役的、缺少規格的情況，針對 artifactPaths.specs.existingOutputPaths 中每個具有 delta 規格的功能——而不僅僅是同步報告已接觸的那些。成功的同步不會留下任何需要應用的東西，因此每個功能現在都必須被讀取為已同步：

   • ADDED 的需求存在
   • MODIFIED 的需求承載了 delta 中命名的新增描述和情境變更，而其餘情境保持不變
   • REMOVED 的需求已消失——並且在此同步退役一個功能（移除了它的最後一個需求，留下空的 ## Requirements）的情況下，其主規格被刪除，而不是留空。
   • RENAMED 的需求以新名稱存在，並且不以舊名稱存在

   如果同步失敗，或任何功能不匹配，請報告差異並停止——不要歸檔。沒有任何東西被移動，且 changeRoot 完好無損，因此使用者可以修復不匹配或重新執行同步並再次開始歸檔。

5. 執行歸檔

   在 planningHome.changesDir 下建立一個 archive 目錄（如果不存在）：

   mkdir -p "<planningHome.changesDir>/archive"
   

   生成目標名稱：當變更名稱已經以 YYYY-MM-DD- 前綴開頭時，按原樣使用；否則，在前面加上目前日期