comet-native

Comet Native

Native は、完全な要件、進捗、受け入れ結果をプロジェクト内に保存します。エージェントは、Runtime で指定されたフェーズのみを実行します。各アクションの後に最新の continuation を読み、タスクが完了するか、ユーザーの判断が必要になるか、外部依存関係によって進行が妨げられるまで、それに従ってください。

必須ルール

• 確認済みの実装、ドキュメントの修正、エビデンスの再利用、復旧を続行します。新たな判断、許可、外部情報が必要な場合は一時停止します。現在の continuation のコマンド、テンプレート、パッケージを使用し、同じタスク内で入力を修正します。
• .comet/config.yaml、現在の変更、comet-state.yaml、ディスク上の正式な成果物を正として扱います。チャットの記憶は補助的なものです。正式なワークフローファイルのうち、エージェントが編集できるのは brief、対象の完全な Specs、関連付けの delta.yaml、children.yaml のみです。状態、チェック結果、レポート、ロック、トランザクションは Runtime が管理します。
• PATH 上の公開 comet native CLI を使用して進めます。ユーザーに手動でコマンドを実行するよう求めてはいけません。コマンドを利用できない場合は、インストールが不完全であると報告して停止します。引数については comet native <command> --help を確認してください。
• CLI で変更を作成し、返されたパスを使用します。再試行する前に、拒否時に示されるコマンドまたは対象に従ってください。カスタム書き込みと Comet 以外の書き込みは、中立的な状態に保ちます。
• Builder はコードを候補実装として提出します。各イテレーションでは、新しい読み取り専用 Verifier がすべての受け入れ項目を個別に評価する必要があります。すべての項目を評価することは、すべてのコマンドを再実行することを意味しません。現在の候補と一致する Runtime のチェック記録は再利用し、不足しているチェック、または無効になったチェックのみを追加します。失敗、ブロック、未実行、タイムアウトとなった作業は、合格として扱えません。
• 確認コマンドを実行するのは、ユーザーが Shape 全体を明示的に確認した後、最終結果を受け入れた後、または該当するデリバリーオプションを選択した後に限ります。Runtime に保存された確認済みの範囲とユーザーの選択を再利用します。Archive、マージ、プッシュ、PR 作成、ワークスペースのクリーンアップに対する許可は、それぞれ別のものです。
• この Skill と Runtime は、外部 Skill に依存せず Native ワークフローを提供します。エージェントは、確認済みの要件と制約を維持する実装方法を選択します。

開始または再開

1. 名前がわかっている場合は、comet native select <change-name> --json を実行します。アクティブな変更がある場合は、返された workspace.projectRoot に移動します。select は status と同じ検出情報および状態情報を返すため、別途 status を呼び出す必要はありません。それ以外の場合は、comet native status --json を実行します。Runtime にワークスペースを特定させます。同じ程度に一致するワークスペースが複数ある場合に限り、ユーザーに確認してください。
2. 一致するアクティブな変更がない場合は、ワークスペースの選択に従って分離方法を選択し、変更を作成してから、preparation.projectRoot に移動します。準備に失敗した場合は、すでに作成されたブランチとディレクトリを保持し、報告された原因に対処してください。
3. ワークスペースに移動して phase を取得した後、メモリ統合に従ってコンテキストを一度取得します。詳細を確認するのは必要な場合に限り、実際の利用結果を記録し、タスク完了時には Project Memory と Personal Memory を個別に扱い、そこで指定されているとおりに comet task --complete を呼び出してください。

タスクの要約、進捗、コマンド出力、テスト結果を Personal Memory に保存してはいけません。学習チェックを完了してください。

プロジェクトの経験と個人の好みは別々に保存します。タスク完了前に、プロジェクトで検証済みの再利用可能な経験を comet knowledge remember で Project Memory に記録します。Personal Memory に記録するのは、ユーザーの好みと安定した協業習慣のみです。コマンドと完了条件については、メモリ統合を参照してください。

アクションに必要なものだけを読む

現在のアクションに該当するセクションを読みます。記載された条件に当てはまる場合に限り、そのセクション内のリンクをたどってください。コマンドリファレンス全体や、すべてのリファレンスを一度に読み込まないでください。

• Shape：プロジェクトの設定に従い、Sequential または Batch のステップを使って、clarificationを読み、手順に従います。大規模なリクエストでは、最終確認の前に、記載されている Supervisor による分解と確認リンクに従います。
• brief、Specs、または children.yaml を編集する前、あるいは受け入れレポートを確認する前に、formal artifactsを読みます。要件の情報源としてファイル、添付ファイル、リンク、またはローカルパスが提供されている場合は、source-document full coverageが必要です。デバッグ、証拠の収集、レビュー、または実装の参考のみに使う資料は、自動的には対象になりません。
• Runtime テンプレートに初めて記入する前、または returnAction を通じて結果を返す前に、filling command inputsを読みます。
• Builder の候補を提出する前に、Builder handoffを読みます。Verifier の起動、チェックの追加、または完了待ちを行う前に、Verify protocolを読みます。
• state に childSummary が含まれている場合、ディスパッチ、結果の受け取り、または統合の前に、Supervisor coordinationを読みます。readyChildren に記載された子と、Supervisor coordination のアクションのみを扱います。
• フィールドが不明確な場合、入力が拒否された場合、Verifier が利用できない場合、実行に失敗した場合、または外部情報が不足している場合は、command inputs and exceptionsを読みます。通常のアクションでは、Runtime が返すコマンドとテンプレートをそのまま使用します。
• 外部入力を待つ場合は、external input and monitoringに従い、独立して進められる作業を続けます。中断、デバイスの変更、進捗の停滞が繰り返される場合、並行処理の競合、移行の失敗、または状態の破損が発生した場合は、fault recoveryを読みます。

Shape

ユーザーに確認せずに確定できる事実を調査します。ユーザーに質問するのは、ユーザーから見える結果を左右し、かつ確実には推測できない判断事項に限ります。簡単なリクエストでは、未解決の質問と依存関係を列挙します。複数の判断が相互に影響する場合に限り、判断ツリーを維持します。native.clarification_mode で質問する前に、このラウンドの未解決の質問を brief に保存します。確認された結論は直ちに該当する brief のセクションと対象の Specs に反映します。未回答の項目には [blocking] を付けたままにします。

要件の情報源がカバレッジの範囲内で完全に処理され、目的別に分類され、結果に影響するすべての判断と前提が解決され、[blocking] が残っておらず、ユーザーが結果、スコープ、重要な判断、すべての受け入れ項目、非目標を明示的に確認し、Runtime が Build に移行した時点で完了です。

新規または再確認された brief には、結果、スコープ、非目標、受け入れ例が必要です。該当する場合は、制約、判断事項、未解決の質問、特別な検証要件を追加します。Runtime は正式なパスと、完全な対象 Spec、または製品の動作に変更がない具体的な理由も確認します。報告された成果物を修正し、続行処理を再実行します。既存の後続フェーズでの変更は、Shape に戻るまで進捗を維持します。

Build ↔ Verify ループ

Builder が候補を提出すると、Runtime は必須チェックを実行し、新しい読み取り専用の Verifier が評価します。失敗した場合は Build に戻って修正し、再提出します。すべての項目に合格したら、ユーザーが結果を承認するまで待ちます。

iteration は実装の提出回数を数え、attempt は同じ候補に対する Verifier の起動回数を数えます。すべてのカウンターは Runtime が更新します。連続した失敗や進捗の停滞が設定済みの上限に達した場合は、最新の指示に従い、ユーザーの判断を待つか、ブロッカーに対処します。

Build

最初の実装の前に、現在のブリーフ、完了済みの対象 Specs、すべての受け入れ項目を読みます。確認済みのスコープ内で、プロジェクトのコードとテストを編集します。修正時は、Verifier が失敗またはブロックされた項目と、失敗したチェックを優先し、その後、確認済みの他の動作も再確認してから提出します。previous_unresolved_ids は修正の重点を示します。次の正式な検証では、引き続きすべての受け入れ項目を確認します。

Build、Verify、Archive では、正式なバインディングを再確認します。新しい Shape は Markdown の内容にバインドされます。空行やソフトラップは確認状態を維持しますが、内容、構造、コード、リンク、または受け入れ項目に変更がある場合は再確認が必要です。編集後、次の実装書き込みの前に Hooks が実際の内容を確認し、Runtime も次の段階への移行前に確認します。既存の Shape はバインディングを維持します。無効なドキュメントやレポートがある場合は、修正アクションを返し、作業を保持します。通常のドキュメントではデフォルトで候補を保持します。厳格な動作にするには native.document_writes: revert を使用します。パスについては正式な成果物を参照してください。

ユーザー Hook の出力には、.comet/config.yaml の hook.allow_paths を使用できます。ユーザー Hook の書き込みを参照してください。

現在の continuation で許可されているアクションを実行する前に、要件の変更を分類します。

• 確認済み機能の実装漏れ：Verify から --revise-implementation を使用し、確認済みのスコープを維持して Build に戻ります。
• ユーザーに見える動作または受け入れ基準の変更：Verify または Archive-ready から --revise-requirements を使用し、正式な成果物を更新して Shape を再確認します。
• 無関係な要件：別の変更として扱います。

ユーザーが現在のスコープへの追加を明示的に指示した場合も、同じルールを適用します。

確認済みの Supervisor Shape ひとつで、そのスコープ内のすべての子タスクが承認されます。Runtime の指示に従ってディスパッチと統合を行い、その後、すべての Supervisor の受け入れ項目について最終検証を自動的に実行します。コーディネーター、Builder、Verifier の責務については、Supervisor の調整に従ってください。子タスクは、Runtime がその検証を受け入れ、統合を確認した後にのみ完了となります。

実装と関連チェックが検証可能な状態になり、Runtime が Builder からの引き継ぎを受け入れ、フェーズが Verify になったら完了です。

検証

変更していないタスクパッケージを使用し、Verify プロトコルに従って、新しい読み取り専用の Verifier を直ちに起動します。プラットフォームが起動を受け入れ、Verifier が verifier-started を報告した後にのみ、実行中として報告します。起動に失敗した場合は直ちに対処します。受け入れ基準のテキストをインラインで指定するか、すべての scopeId をページ送りして確認します。Verifier はすべての受け入れ項目を個別に評価し、実装、ワークスペース、入力が一致する Runtime のチェックを再利用して、不足または無効になったエビデンスを追加します。必要に応じてファイルとログを読み取ります。

wait ツールがタイムアウトした後も、同じ Verifier を待ち続けます。結果受領情報がなく、応答もない場合は、起動が成功したか確認します。エラーを報告するのは、失敗、実行タイムアウト、タスクの消失、または利用可能な結果を得ずに完了したことが確認された場合に限ります。Runtime が結果を受け入れた後は、現在の状態に従います。自動チェックのみの結果も含め、ユーザーが明示的に受け入れた後にのみ --accept-result を実行します。ワークスペースが分離されている場合は、--finish を指定して、結果の受け入れと引き渡し方法の選択を 1 回の返信で行います。完了方法が選択されていない場合は、別途確認します。

Runtime が各判定を受け入れ、次のアクションを提示したら完了です。Build で修正を続けるか、指定された待機条件またはブロック条件に対処します。フェーズが終了しても、タスクが完了したことにはなりません。

アーカイブ

continuation で Archive が許可された場合は、Archive completion を読み、受け入れ済みの結果を再利用して、continuation に従います。完了方法の選択が明示された後、その --confirmed --finish コマンド全体を実行します。Runtime がトランザクションの事前チェックと再チェックを行います。ドライランが返された場合は、プレビューし、ready: true の後に、その一意の確認済みコマンドを実行します。返されたブロッカーに対処します。

この変更の実装と正式な成果物のみをコミットし、無関係な編集は保持します。workspaceFinishResult を調べ、ワークスペースを保持し、ブロックされた場合は recoveryArgs に従います。既存の許可範囲内でコミットメッセージとローカルのブロッカーを修正して続行します。新たな許可または外部情報が必要な場合にのみ確認します。

状態が done で、許可されたワークスペースの完了処理が completed または kept となり、メモリー統合を通じてタスク完了が記録されたら完了です。それ以外の結果への対応も続けます。

続行

• continue：返された作業ディレクトリで commandArgs 全体を実行し、inputOptions のテンプレートから入力値を補います。
• await-user：userCommunication.message と suggestedReply を伝え、記載された選択を待ちます。--expected-state-version と --expected-action を保持したまま、該当する commandAlternatives を実行します。状態が古い場合は最新の状態を読み取ります。ガードのないコマンドを組み立ててはいけません。
• blocked：記載されたブロッカーまたは復旧アクションに対処し、依存する作業のみを一時停止します。
• done：Archive の完了基準を確認してから終了します。

agent を含む正常な応答を受け取った後は、共有ワークフローガードの軽量な所有権確認結果を再利用し、応答に含まれるフェーズ、状態バージョン、workspace.cwd、continuation に従って続行します。フィールドが不足している場合、バージョンまたは所有権を理由にコマンドが拒否された場合、またはアクションに追加の成果物テキストが必要な場合にのみ、詳細を読み取ります。新しいセッション、応答状態を伴わない圧縮からの復旧、リポジトリ／ブランチ／変更の切り替え、または明確な外部変更があった場合に限り、status を再度照会します。wait ツールがタイムアウトしても、既存の Verifier や子タスクを再ディスパッチしてはいけません。

受け入れ基準のテキスト、引き継ぎの要約、または履歴が現在のアクションに必要な場合にのみ --details を追加します。すべての scopeIds を網羅するまで nextPageArgs に従ってページを進めます。成果物の本文が必要な場合にのみ show を実行します。CLI のテキストでは、まず summary、単一の NEXT:、およびリレー・メッセージがあればその内容を読み取ります。プログラムによる解析には --json を使用し、ローカル実行の診断にのみ --verbose を使用します。