william-london/ownframework-loop

OwnFramework Loop - 仕様

このスキルは、決定論的なofloopコアに対するホストアダプタです。

ルール

• 自分自身のパケットを承認してはなりません。
• STATE.json、APPROVAL.json、REVIEW_VERDICT.json、イベントログ、ロックファイルを直接書き込んではなりません。
• TTY確認トークンを生成してはなりません。
• push、merge、deploy、publish、send、payment、または無関係なリモート権限を追加してはなりません。

新仕様（通常フロー）

1. 作業ディレクトリが対象のGitリポジトリであることを確認します。

2. ランを作成する前にリポジトリの同一性を解決します：

   • 設定済みのGitリモートを検査します。
   • 意図した将来の状態ではなく、実際の現在の状態からパケット分類を決定します。
   • local_only は設定済みリモートがないことを意味します。
   • プライベートGitHubレビュー面がプロジェクトの一部である場合は、それを作成・設定し、意図したベースラインをプッシュし、ローカル/リモートの一致を証明してから、ofloop spec new の前に github_private を使用します。
   • ローカルオンリーのランを作成し、後からリモートを追加しないでください。

3. 正確な境界のあるパケットを作成するのに十分なリポジトリコンテキストのみを検査します。

4. ofloop spec new <repo> "<mission>" を使用してランを作成します。

5. リポジトリのスキーマとパケット規約を使用して WORK_PACKET.md を作成します。 ホスト/ツールのニーズに対しては、マシンパスを埋め込んだりツール固有のネットワークトポロジーを手動で再構築したりする代わりに、ポータブルな capabilities を宣言します（例：toolchain.python、package.uv、browser.playwright.chromium）。runner_profile は、ミッションにオペレーター委託のモデル/努力ポリシーが必要な場合にのみ、信頼されたプロファイル名として使用します。パケットが生のClaudeフラグを運ぶことはありません。network_read_allowlist は、能力契約によって既に提供されていないパケット固有の追加読み取りホストにのみ使用します。広範なワイルドカード、スキーム、ポート、パス、公開エンドポイント、デーモンソケット、無関係なホストを追加しないでください。エンキュー前に、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. 停止。通常のバックグラウンド操作はスーパーバイザー優先です。ランをエンキューします。既に委託されたスーパーバイザーサービスがそれを消費するか、ofloop supervisor serve で実行クロックを手動で実行できます。最初の実行可能なBUILDが、自動的に不変の実行シールを作成します。

内部状態とオペレーター向け状態

内部ストレージ名 AWAITING_APPROVAL は下位互換性のために保持されています。オペレーター向けの意味は READY_TO_START（ランは開始可能であり、承認手続きは不要）です。

互換性のみ：レガシーTTY事前シール

オプションの歴史的なTTY事前シールコマンドは、下位互換性のある/オプションの厳密な事前シールとして残されています。通常のワークフローでは必須ではなく、オペレーターの指示に含めてはなりません。

パケットの不変性

最初の実行シール前：サポートされている修正インターフェースを通じてパケット修正が可能です。

実行シール後：パケットは不変です。ミッション/スコープを変更するには新しいランが必要です。

実行前のリポジトリ同一性

target.classification は仕様時点のリポジトリ同一性であり、将来のデプロイ希望ではありません。プライベートGitHubレビュープロジェクト向けのランは、プライベートリモートとベースラインブランチが存在し、ローカルHEADが意図したリモートベースラインと等しいことが証明された後にのみ作成する必要があります。

spec new 後、最初の実行シール前にリモートトポロジー/分類が変更された場合は、開始されていないランを停止し、最終的なリポジトリ状態から新しいランを作成することを推奨します。最初のBUILDクレームに依存して、予防可能な local_only + リモートミスマッチを発見しないでください。

現在のコア実行は、local_only パケットに設定済みリモートがある場合、すでに障害時にクローズします。仕様ワークフローは、通常の操作でその拒否に到達するのを防ぐ必要があります。

PROGRAM自律性事前確認

v3 PROGRAMが準備完了と見なされる前：

• チェックポイントで acceptance_criterion_ids を使用します。チェックポイント acceptance_criteria を発行しないでください。
• ミッションに必要な最小限のポータブルな capabilities セットを宣言し、エンキュー前に事前確認します。実効的なネットワーク読み取り権限は、パケット固有の network_read_allowlist ホストと正確な能力派生ホストの凍結された和集合です。したがって、パケットリストが空の場合は追加のパケットドメインがないことを意味しますが、宣言されたパッケージ/ブラウザ機能が狭いダウンロードエンドポイントを必要とする場合、必ずしもゼロドメインを意味するわけではありません。
• runner_profile は、ofloop capabilities profile <name> によって公開された信頼されたプロファイルからのみ選択します。明示的なモデルは、移動するClaudeエイリアスではなく、固定されたプロバイダーモデルIDである必要があります。明示的な努力も、現在のClaudeランタイムで ofloop capabilities attest-effort <name> が必要です。プロファイルIDはランにバインドされており、セマンティックモデル/努力のみを選択できます。サンドボックス/ツール/MCP/セッション権限は選択できません。
• 最初の実行前に、パケット予算を実行可能な上限に対して検証します。
• トップレベルのbuild/review/repair値を累積的なプログラムエンベロープとして扱います。
• 意図的にプログラム全体をスロットリングしない限り、それらのグローバルエンベロープをチェックポイントローカル予算の合計から資金を提供します。
• グローバル修復許容量がグローバルビルド/レビュー許容量によって実現可能であることを確認します。
• 1回のセマンティックパスの複雑さに応じて max_pass_runtime_seconds を選択します（パスあたり最大28800。宣言されていないフォールバックフューズは3600であるため、正当に1時間以上かかるパスはその予算を宣言する必要があります）。
• プログラムが正当に長時間実行される可能性がある場合（最大2419200）、risk_budget.max_runtime_seconds をラン全体の壁時計エンベロープとして宣言します。supervisor enqueue はこれを運用上の壁上限として消費します。これがない場合、壁時計上限は適用されず、ランはセマンティックパス/修復/無進捗保護によってのみ制限されます。

モデルがすでに作業を行った後にのみ不可能な決定論的上限を発見できるパケットは、仕様の欠陥であり、開始可能であってはなりません。

無人予算セマンティクス

トークン上限はデフォルトでオフ、コスト上限もデフォルトでオフです。無人実行は、意味のある進捗保護（パスと修復の上限、無進捗ストリーク、同一発見繰り返しフューズ、失敗クラス再試行ポリシー）によって制限され、トークンやコストの節約によっては制限されません。ハードな支出ラインを希望するオペレーターは、エンキュー時に --max-cost-usd / --max-total-tokens / --max-wall-seconds を明示的に渡すことができます。正の総コスト上限が資金提供されると、スーパーバイザーは各Claudeプリントモードパスを残りの耐久実行予算で狭めます。Loop台帳が正規の総計会計ソースのままです。