william-london/ownframework-loop

OwnFramework Loop - 規格

此技能是確定性 ofloop 核心的主機適配器。

規則

• 絕不批准自己的封包。
• 絕不直接寫入 STATE.json、APPROVAL.json、REVIEW_VERDICT.json、事件日誌或鎖定檔案。
• 絕不偽造 TTY 確認令牌。
• 絕不執行 push、merge、deploy、publish、send、payment 或任何無關的遠端授權操作。

新規格（正常流程）

1. 確認工作目錄是目標 Git 倉庫。

2. 在建立 run 之前 先 解析倉庫識別：

   • 檢查已設定的 Git 遠端；
   • 根據實際當前狀態（而非預期未來狀態）決定封包分類；
   • local_only 表示沒有已設定的遠端；
   • 當專案包含私有 GitHub 審查表面時，建立/設定它，推送預期的基準線，證明本地/遠端一致性，然後在 ofloop spec new 之前使用 github_private；
   • 不要建立一個僅本地 run 然後事後才新增遠端。

3. 僅檢查足夠的倉庫上下文以草擬一個精確的限制性封包。

4. 使用 ofloop spec new <repo> "<mission>" 來建立 run。

5. 使用倉庫慣例和封包慣例草擬 WORK_PACKET.md。 為主機/工具需求宣告可移植的 capabilities，而不是嵌入機器路徑或手動重建工具特定的網路拓撲 （例如 toolchain.python、package.uv、 browser.playwright.chromium）。僅在任務需要操作員委託的模型/工作量政策時，使用 runner_profile 作為受信任的設定檔名稱；封包絕不攜帶原始 Claude 旗標。僅在封包需要由能力合約未提供的額外讀取主機時，才使用 network_read_allowlist。 絕不新增廣域萬用字元、協定、埠、路徑、發布端點、守護行程 socket 或無關主機。 在排入佇列之前，執行 ofloop capabilities probe 檢查主機，並執行 ofloop capabilities preflight <repo> <capability>... 檢查確切請求的集合。如果請求的普通能力不可用，請在主機上佈建或委託它，或修改封包後再執行；不要放寬 HOME/PATH 或回退到無沙箱執行。特權能力 container.docker / local.http-service 還需要操作員擁有的金絲雀委託流程。

6. 對於具有檢查點特定結果的 PROGRAM 封包，請將完整的任務接受合約保留在頂層，並透過每個檢查點的 acceptance_criterion_ids 確定性地分配它。如果任何檢查點使用範圍性的 AC ID，則每個檢查點都必須宣告一個非空列表，並且聯合必須涵蓋每個頂層 AC ID。不要為了滿足覆蓋範圍而對未來檢查點標準使用 not_applicable。

7. 使用支援的驗證器驗證封包形狀。

8. 返回給操作員：

   • repo
   • run_id
   • packet_sha256
   • spec_baseline_branch / spec_baseline_sha
   • execution_mode / checkpoint_count
   • 規範的無人值守排隊：ofloop supervisor enqueue
   • 規範的狀態查詢：ofloop supervisor status
   • 當尚未作為服務執行時的執行時鐘：ofloop supervisor serve
   • 僅供 Claude 適配器前景/除錯使用：/of-loop:build
   • 僅供 Claude 適配器前景/除錯使用：/of-loop:review

9. 停止。正常的背景操作是 supervisor 優先。排入佇列 run； 一個已委託的 supervisor 服務會消費它，或者可以手動執行 ofloop supervisor serve 來執行時鐘。第一個可操作的 BUILD 會自動建立不可變的執行封印。

內部狀態 vs 操作員面向的狀態

為向後相容保留了內部儲存名稱 AWAITING_APPROVAL。 操作員面向的含義是 READY_TO_START（該 run 可啟動；不需要批准儀式）。

僅相容性：舊版 TTY 預封印

可選的歷史性 TTY 預封印命令作為向後相容/可選的嚴格預封印保留。 正常流程不需要它，且不得出現在操作員說明中。

封包不可變性

在首次執行封印之前：透過支援的修改表面支援封包修改。

執行封印之後：封包是不可變的。變更的任務/範圍需要一個新的 RUN。

執行前的倉庫識別

target.classification 是 spec 生成時的倉庫識別，不是未來的部署意願。 一個針對私有 GitHub 審查專案的 run，僅應在私有遠端和基準線分支存在，且本地 HEAD 被證明等於預期的遠端基準線之後才建立。

如果在 spec new 之後、首次執行封印之前，遠端拓撲/分類發生了變化，建議停止從未啟動的 run，並從最終的倉庫狀態建立一個全新的 run。不要依賴首次 BUILD 宣告來發現可預防的 local_only + 遠端不匹配問題。

當前的核心執行已經在 local_only 封包設定了遠端時閉合失敗。spec 工作流程應防止在正常操作中達到該拒絕狀態。

PROGRAM 自主前置檢查

在 v3 PROGRAM 被視為準備就緒之前：

• 在檢查點上使用 acceptance_criterion_ids；絕不發出 checkpoint acceptance_criteria；
• 宣告任務所需的最小可移植 capabilities 集，並在排入佇列之前對其進行前置檢查。有效的網路讀取權限是封包特定 network_read_allowlist 主機與確切能力衍生主機的凍結聯集。因此，空的封包列表意味著沒有額外的封包域，但當已宣告的套件/瀏覽器能力需要狹窄的下載端點時，不一定意味著零域；
• 僅從 ofloop capabilities profile <name> 暴露的受信任設定檔中選擇 runner_profile；明確的模型必須是固定的提供者模型 ID，而不是變動的 Claude 別名。明確的工作量也需要在當前 Claude 執行環境上執行 ofloop capabilities attest-effort <name>。設定檔身份是與 run 綁定的，可能僅選擇語義模型/工作量，從不選擇沙箱/工具/MCP/會話權限；
• 在首次執行之前，根據可執行上限驗證封包預算；
• 將頂層的 build/review/repair 值視為累積的 PROGRAM 信封；
• 除非故意限制整個 PROGRAM，否則從檢查點本地預算的總和為這些全域信封提供資金；
• 確保全域修復津貼可由全域 build/review 津貼實現；
• 根據單次語義傳遞的複雜度選擇 max_pass_runtime_seconds（每次傳遞最多 28800；未宣告的後備熔斷器為 3600，因此任何需要超過一小時的合法傳遞都必須宣告其預算）；
• 當 PROGRAM 可能合法執行較長時間時，將 risk_budget.max_runtime_seconds 宣告為整個 run 的掛鐘時間信封（最多 2419200）。supervisor enqueue 將其作為操作性的掛鐘上限消費；沒有它，則沒有掛鐘時間上限，run 僅受其語義傳遞/修復/無進度保護的約束。

一個只能在模型已執行一些工作後才發現不可能的確定性上限的封包，是一個 spec 缺陷，絕不應可啟動。

無人值守預算語義

令牌上限預設為關閉，成本上限預設為關閉。 無人值守執行受有意義進度保護（傳遞和修復上限、無進度連續失敗、相同發現重複熔斷、失敗類別重試策略）的約束，而非令牌或成本節約。希望設定硬性支出線的操作員可以在排隊時明確傳遞 --max-cost-usd / --max-total-tokens / --max-wall-seconds。當設定了正數的總成本上限時，supervisor 還會使用確切的剩餘持久化 run 預算來縮小每個 Claude 列印模式傳遞的範圍；Loop 帳本仍然是規範的總計核算來源。