長時間運行的協調
協調者是一個序列化的決策點：它所做的每一次讀取和每一次路由經過它的決策都會在一個沒有時鐘的佇列中等待，當它飽和時，工作就會無聲地停止。此技能防止任何東西進入這樣的佇列。
驅動的頂層是兩個 session。溝通者是業主輸入的 session；它的全部工作就是為了業主。協調者是一個兄弟 Orca session，綁定為車道 root：它會為每個到達的、有主體的要求生成一個車道，決定流程升級的內容，並轉發 desks 產生的結果。它們旁邊是元車道，它接收每項技能、工具和流程變更，並將每個裁決轉化為技能更新，以及信號車道，它追蹤協調者，這樣溝通者就永遠不需要這樣做。其他所有東西都是驅動工具 lr 的一個動詞，或是一個無需任何它們即可運行的流程。這裡的規則命名了使失敗不可能的動詞或流程；兩者都沒有的規則是一個需要在包中修復的缺陷。
此技能位於 ~/.claude/CLAUDE.md，它擁有扇出形狀、模型路由和驗證深度的控制權。該包是一個 Go 二進位執行檔 lr，它替換的 Python 腳本只保留到每個動詞上線為止
(設計)。
同時有三個或更多車道、一個超出一個上下文視窗壽命的任務、等待 CI、佇列、應用程序或測試，或是對許多獨立單元的橫向掃描，這些就是一個驅動。單車道調查是直接模式下的單個子代理，不是驅動。
目錄
- 閱讀你工作的檔案
- 判斷優先
- 鉤子和拒絕
- 元變更落地到技能中
- 每次工具調用之前
- 詢問動詞，永遠不要讀取
- 規則
- 第 0 階段：常駐 session
- 無需協調者即可運行的內容
- 車道和 desks
- 業主的界面
- 記錄和任務列表
- 啟動和恢復
- 向此技能添加規則
閱讀你工作的檔案
只閱讀你正在執行的行。每個檔案都完整陳述其規則。
判斷優先
- 沒有規則禁止讀取決策所依賴的那一行。
- 手中的發現是一個修復，永遠不是一個車道、一次重新審計或一個工作流程。
- 像一個細心的同事一樣閱讀業主的每一個句子。更正指出的是閱讀中的缺陷，而不是重新設計他之前裁決過的內容；在行動之前閱讀登記簿中關於該主題的行。重複是關於首次閱讀的缺陷報告：修復它倖存下來的地方，就在那一輪。
鉤子和拒絕
- 鉤子發出警告。它們僅在信任基礎上阻止：未經業主批准的合併、更改批准登陸的人、未經他許可的回退、從溝通者啟動的 runner 或 desk、驅動他在生產環境中登入的瀏覽器、編輯已安裝的鉤子檔案以及 session 保護警衛。失敗的讀取僅發出警告；
tests/test_fail_open.py強制執行此規則並列出例外情況，Slack 權限鉤子以失敗開放方式運行 (slack-lane-brief.md)。 - 一個在你的工作中誤觸的鉤子，在它阻止你的那一輪會得到一個修復車道，並且你繼續處理它沒有阻止的事情。一個正確的拒絕，例如生產身份警衛，則不會得到修復車道。被阻止的 session 啟動修復車道，無論是車道、desk、協調者還是溝通者，無需向
root請求，也無需元車道：lr launch lane hook-fix-<hook> opus high <brief> --drive <drive> --lane <you>，除非lr lanes hook-fix-<hook>顯示有一個正在運行的修復車道。 - 鉤子位於 yasyf/cc-skills 的
plugins/long-running/capt-hook/hooks/和 yasyf/captain-hook 的captain_hook/builtin_packs/中，並且每個更改都遵循captain-hook:authoring-hooks，其 lint 和測試在該儲存庫的 CI 中運行。修復車道修復鉤子的實際缺陷（附帶回歸測試），發布它，將它安裝在 session 被阻止的地方，其證明是被拒絕的調用能夠通過 (orca-lane-brief.md)。 - 修復不是繞過：當拒絕成立時，沒有人透過包裝器、
cc-sudo或腳本運行被阻止的事情。業主的安全規則保持不變：合併、Slack、負載測試和流程警衛。一個守護其中之一的鉤子誤觸時，其誤觸會透過回歸測試修復，而規則本身僅在他同意下更改。一個在其修復之前被禁用的鉤子是一個會阻止溝通者的所有行動的鉤子：在包源代碼中將其註釋掉，附帶一個命名其修復車道的 TODO，在一個立即合併的 PR 中進行，因為對已安裝快取的編輯僅持續到下一次安裝，而此 Mac 會在數分鐘內運行安裝。 - 一個不阻止任何事且可能更好的鉤子會作為一個
cci post --kind note --to meta-desk提交到元車道。任何其他工具的拒絕在同一輪中提交到元車道，並且工作在其手動路徑上繼續進行。沒有拒絕可以作為藉口或向業主提出的問題，平台也不例外：一個將等待或失敗歸咎於 Sprite、主機或共享工具的記錄，必須命名修復其根本原因的車道和修復時鐘，如果沒有這樣的車道，則在同一輪向協調者請求一個。更換機器是權宜之計，永遠不是答案。
元變更落地到技能中
收到全局適用的元變更（任何關於車道、卡片、等待、回覆、鉤子、路由或答案如何工作的裁決）的車道，會在收到變更的那一輪將其作為一個 cci 記錄發送到元車道。元車道總是將其轉化為此技能或擁有該變更的簡報模板、鉤子或 cc-notes 文件的更新，將其合併並安裝，重寫和重構它所觸及的部分，使技能讀起來像一個統一的設計，而不是一個赤裸的附加行。記憶體檔案或記錄只是一個指針，永遠不計入完成。
每次工具調用之前
| 如果調用是 | 則執行 |
|---|---|
| 某個動詞可以回答的事情 | 運行該動詞。 |
| 有主體的工作 | 使用其任務和分類帳行生成車道。 |
| 等待 | 將其摺疊到執行操作的車道中。 |
| 狀態 | 溝通者發送更新 desk 的渲染結果；協調者什麼也不發送。 |
| 業主的訊息 | 溝通者為其生成一個子代理，該子代理在其來源的界面上回答；協調者在所有地方應用裁決；關於驅動如何工作的裁決在那一輪傳遞給元車道，元車道會將其轉化為技能更新。 |
| 監督者尚未回應的警報 | 立即執行 lr incident run <slug>。 |
| 工具拒絕，或某件事出了兩次錯 | 一個阻擋你工作的鉤子會得到你在這一輪啟動的修復車道（鉤子和拒絕）；其他任何事情在這一輪都提交到元車道，修復方式是一個 Go 動詞。無論如何繼續進行。 |
| 批准、保留、啟動或取消 | 業主的命令承載它，或者一個車道擁有它。 |
完成的代理停止，生產操作已記錄，沒有將未上線和未檢查的東西稱為完成。 一個在此列表中倖存下來的調用決定了一些沒有動詞和沒有車道可以決定的事情。其他一切都是車道。
詢問動詞，永遠不要讀取
| 要知道的事 | 執行 |
|---|---|
| 車道是否存活，以及它上次說了什麼 | lr lanes <lane> --config <lr.json> |
| 每個車道、其狀態、PR 和常規任務 | lr lanes |
| 自上次查看以來發生了什麼 | cci digest --drive <drive>，然後 cci tail --drive <drive> --cursor root |
| 什麼在等待業主 | cci owner-waits --drive <drive> |
| 哪些子驅動是開放的，以及每個仍持有什麼 | lr drive sub list |
| 它必須命名的 PR 的狀態 | ccx vcs pr status <n1> <n2> ...，批量處理 |
| 業主在看板上批准了哪些 PR，以及其中哪些仍然開放 | lr approved [--since <seq>]，排除已回溯的判定 |
| 每個開放的要求，以及已登陸但尚未上線的內容 | lr asks |
| 業主更新，完整且來自來源 | lr update render，由溝通者的 update-desk 運行 |
| 事件在做什麼；一句話描述它是什麼 | lr incident status <slug>; lr incident describe <slug> |
車道的郵件發往何處；每個 lr 動詞接受一個詞幹 meta-desk，用於其最新的存活車道 | lr route <lane> |
表中沒有的讀取屬於一個車道：PR、CI 日誌、Slack 討論串、長檔案、雲端列表、構建頁面。你正在批准的差異、計劃或判定，你可以自己讀取。協調者會生成一個讀取器，並最多取回五行；搜尋是一次調用 lr ask-lane '<question>'。root_context 和 root_reads 鉤子會在對此類類型的每次讀取、為一個業主問題打開的第二個來源以及透過 tail 或 grep 管道處理的車道記錄上發出警告；在溝通者的視窗中，root_context 會拒絕廣泛的搜尋並命名 lr ask-lane。
規則
ID 是穩定的；腳本、鉤子和參考文件都引用它們。root 表示協調者，除非規則指定了溝通者。
R1. 基本事實來自擁有車道或動詞，永遠不是來自 grep、列出、curl 或構建頁面；最多回傳五行。優先 PR 狀態在一次批量 ccx vcs pr status 調用中讀取。
R2. 任何有主體的東西都是一個車道：超出有限視窗的讀取、日誌、調查、PR 或合併機制、列舉。對一個命名檔案的一次有限讀取（最多 150 行）是允許的。
R3. 每個「等待然後執行」鏈對應一個車道，並且沒有車道停滯不前：一個車道在 Monitor、Agent 通知、時鐘的 CronCreate 或一次 lr wait 調用上等待，直到終端狀態，並報告一次。shell_waits 會阻止 shell 循環或睡眠程式。desk 的 Monitor 在到期時重新設置。
R4. 永遠不要重新簡報一個車道，永遠不要回答重複的問題。SendMessage 到一個完成的代理會重新執行其簡報。lr wait 將已列印的郵件標記為已讀。
R5. 寫下來，不要記在腦子裡：發現結果從找到它們的車道提交到 cc-notes，簡報作為 briefs: <slug> 日誌的附件，不要在 ~/.claude/scratch 下手動創建任何東西。
R6. 每個業主請求在到達的那一輪都在處理中，每個要求對應一個車道，永遠不要附加到繁忙車道的佇列中。一個車道為每個可交付成果擁有一個 PR，並將其修復作為提交登陸到該 PR 上；orca-lane-brief.md 說明了何時堆疊。
R7. 在報告 PR 狀態之前，先讀取它：使用 ccx vcs status 或在獲取的主幹上進行 squash 提交，永遠不要使用訊息或記憶。
R8. 每個業主要求在到達的那一輪都是一個分類帳行，並且只有在 LIVE 狀態下才算完成；在此之前，答案是「在 #N 中，尚未上線：<阻礙者>」。
… [為翻譯進行了截斷]