共有ポリシーの場所: docs/DISCOVERY.md、docs/WORKFLOW.md、
docs/LAUNCH-MIGRATION.md、docs/STANDALONE-ENTRY.md、docs/PROCESS.md、docs/using/README.md および docs/using/mirrors.md は、解決された Hatsu プラグインルート に属し、利用リポジトリには属しません。インストールされたサーフェス上では、ten が出力する絶対ルートを使用してこれらのファイルを読み取ってください（そのスキルを通じて再解決します）。以下の相対リンクはソースの場所を特定します。コンシューマーの docs/ コピーがないことはポリシーの欠如ではなく、重複ファイリングをトリガーしてはなりません。ターゲットリポジトリに 2 つ目のポリシーをコピーしたり作成したりしないでください。
Aka — ブランチが出ていく
性質: 操作系。 プッシュは定義上、共有状態に対する git 側の操作であり、どの性質が差分を作成したかは問いません。
Lint し、未公開の履歴のみを折り畳み、ベースをその下に置き、ツリーが動いた場合は再 lint し、その正確なツリーをリモートにプッシュする。PR はなし。プロジェクト全体のテストはなし。
Aka はローカルプレーンにおける 最初の人間による呼び出し です。それ以前のすべて — hatsu:ren のターン、hatsu:kokusen のコミット — は、マシンから出ないため、尋ねられることなく発生します。Aka は、作業が他の誰かがフェッチできるものになる場所であり、その境界線を越えるのはメンテナーの判断です。
プルリクエストは開きません。 それは hatsu:mukai の実行であり、その中の hatsu:shibari のステップです。Aka はプッシュされたブランチで終了し、それ以外は何もしません。意図的です。プッシュと PR は 2 つの決断であり、それらをまとめると、一方を尋ねることができなくなります。
0. スタンドアロンエントリ — このスキルは元々メンテナーの呼び出しでした
Aka に配線されたエントリはありません。 § 1 ですでに述べています。スキル全体はメンテナーの公開指示があった場合にのみ実行され、エージェントは決してそれを提案しません。最初の切り分け、2026-09-28 付けメンテナー裁定 (b)
(docs/ROSTER.md § 2026-09-26/27/28 の裁定): 型付き futon 呼び出しでこのスキルを指名する then ステップは、メンテナーの公開指示そのものです — 先行する go mugetsu § 3 が定義する — それでもプロンプトは出されず、提案もされません。docs/STANDALONE-ENTRY.md § 6 は、これをレポート、ベル、ストップのオプション、コンポジットが決して提供してはならないフェーズの一つとして挙げています。スタンドアロン実行はまさに、そのような提供がパイプラインが最善を知っているかのように読まれる場所です。
2 番目の切り分け — 型付きコンポジットの委譲された公開 — メンテナー裁定
HR-20 (zheref/hatsu#332)、docs/ROSTER.md § 2026-10-19 の読み解き — 型付きコンポジットの委譲された公開 をそのまま批准します。これはすでに行われた 2 つの裁定に基づいています。kazaana の委譲は、キューに入れられた各イシューを 作成および公開 します（ROSTER § 2026-10-13 の裁定、裁定 1）。また、統合ブランチ上の futon エフォートは、aka を実行して 自身のエフォートブランチを公開 します（ROSTER § 2026-09-30 の裁定 — En は決してマージしない、行 エフォートが停止する場所）。スタック形式またはイシュー単位の形状では、そのプッシュは futon § 4 → build § 5 のものです。型付き futon または kazaana 呼び出しは、作成者を実行するワーキングブランチに対するメンテナーの公開指示です — コミットごとではなく、1 回の指示です。
| 型付き futon / kazaana ラインの範囲 | |
|---|---|
| 対象 | 実行のキュー内のエフォートごと：その 最初の公開（ビルダー委譲またはセッション内でのこのスキル — kazaana § 3; build § 5）および、それを届ける すべてのメンテナンスコミットとプッシュ — レビュー修正、キャッチアップ、レビュー後の修正（mukai および en 内の murasaki § 6）— 実行のターゲットリポジトリとそのエフォート自身のワーキングブランチ に対して、このスキルと murasaki のゲートを変更せずに通過 |
| 対象外 | 別のリモートまたはリポジトリ、別のブランチ、branch.base、force 形式または公開済みコミットの書き換え、タグ、マージ、リリース。対象外の行の外では、プッシュの可否はそれを所有するスキル自身のルールに依存します：すでに公開されたブランチに対する murasaki § 6; futon § 5 の 統合ブランチ（nen wc publish でのみプッシュされ、aka を経由せず、フォースもされない — ROSTER § 2026-09-30 の裁定 — En は決してマージしない）;getsuga § 3/§ 3a（提案ブランチ用）および § 4（タグ用の カット）。スタックされた子のリターゲットはマージ計画のものです（WORKFLOW.md § スタックされたプルリクエスト ルール 5; ROSTER § 2026-10-12 の裁定）。どのスキルも行為を所有していない場合、その行為は実行されず、報告されます。それがメンテナーのみが実行できる行為である場合にのみ G5 となります |
| 失効 | 実行が終了したとき（futon § 10）、停止時、または実行を停止する G5、あるいはメンテナーの言葉による — コミットが変更されたためではありません。エフォート自身の G5 はそのエフォートの範囲のみを失効させます — 他のエフォートの範囲は失効させません — メンテナーが応答したときに再開します。G2/G4 マージプロンプトは何も失効させません（mugetsu § 3 のとおり）。再開、再起動、または圧縮されたセッションは、新しい型付き呼び出しがあった場合にのみそれを保持し、チェックポイント、実行記録、サマリーからではありません |
範囲は宛先であり、SHA ではありません。 同じリポジトリの同じブランチに対する新しいコミットは範囲内です。コミットが移動したからといって再度尋ねることは、#332 が記録する失敗です。すべてのハンドオフがそれを運びます — 親からビルダー委譲へ（kazaana § 3）およびその後のすべてのメンテナンスステップ（mukai、en、murasaki）：5 つの事実のレコード — 呼び出しを 逐語的に引用、プッシュも依存するメンテナーの応答（ある場合）、リポジトリ、ワーキングブランチ、および 範囲: このブランチへの最初の公開とメンテナンスプッシュ、実行が終了するまで。チェックポイント、実行記録、または後のハンドオフは、決してそれを正確なコミットに限定しません。古い行が別のことを述べている場合、後の修正が それに取って代わり、並存することはありません。
レコードはすべてのハンドオフ（メンテナンスのものを含む）を、すべてのサーフェスで同じように生き残ります。
(zheref/hatsu#529)。この段落は 3 つの行のいずれも拡張しません。
セレクターのキュー外の前提条件は、型付きラインの対象外です。そのプッシュは、その公開を許可するメンテナー自身の言葉（§ 1 の呼び出し、その人の言葉で）のみに依存し、2 番目の事実として引用され、実行のターゲットリポジトリに対して行われます。準備のみを承認する応答はプッシュを許可せず、1 回だけ尋ねられます。アイドル状態の実行の統合配信は futon § 5 のままです（上記対象外）。そのリクエストは同じ事実を運び、futon § 5 をその権限として引用します。ホストの承認が必要なルーチンプッシュは、リクエスト内にそのレコードを提示します — Codex の場合、サポートされているレビュールートの正当性証明（docs/surfaces/codex.md § 公開リクエスト）— そのため、アクター、ワークツリー、またはコミットが変更されても、メンテナーに再度尋ねる理由にはなりません。ホストが決定することはホストの決定のままです。レコードはレビュー担当者への証拠であり、決して自己許可ではありません。範囲外の宛先、保護されたベース、書き換え、またはリリース行為は拒否されるか、独自のゲートの背後に残ります。実際の拒否は次の段落の内容です。境界のあるケースは docs/ab/publication-authority.md にあります。
ホストの拒否はホストのものです。 ハーネスの承認レイヤーが範囲内のプッシュを拒否した場合、その拒否は 呼び出しと範囲とともにメンテナーに引用され、そのホストがサポートする承認パスのみを通じて解決されます — メンテナーの行為：そこでの承認、または同じルートを通じた再送信で、新たに与えられた言葉をレコードと並べて引用するもの（zheref/hatsu#529）— 証拠のみでの再試行は決して行わず、同じプッシュに対する別のコマンド、ルート、サーフェスも決して使用せず、より広い許可を求めたり、権限設定に触れたりすることもありません。そこでの正確な承認は、自身のアクションに対する有効な受領証のままとなり、何も拡張しません。
代表的な軌跡。 hatsu:kazaana zheref/nen → 委譲の aka がコミット A で <model>/kurapika/<slug> を最初に公開 → mukai が PR を開く → en：レビューされた問題が修正され、kokusen がコミット B を作成し、murasaki が B を同じブランチにプッシュ。両方のプッシュは単一の型付きラインに基づいており、どちらも尋ねません。B が他のブランチにプッシュされた場合は範囲外であり、対象外の行に従います。
2 つの切り分けは別々のままです。 then aka ステップは最初の切り分けの単回使用の go です。2 番目はコンポジットのエンジンが行うエフォートごとのプッシュのみをカバーします。スタンドアロンの hatsu:aka は変更ありません — 1 回の呼び出し、1 回の実行（§ 1）— どちらの切り分けも branch.base へのマージ（en § 5 のプロンプト）やリリース（getsuga、mugetsu）には及びません。
P1 が適用されます — hatsu:ten aka。これにより、このフェーズの前提条件が最新になります（ten § 6）。P2 はスカッシュ前のレポートに属します：ブランチ、クリーンかダーティか、未プッシュのコミット数、およびリモートにすでにあるもの。§ 4 は 未プッシュの コミットのみをスカッシュし、その境界はリモートから読み取られ、決して記憶されません。
その他は変更ありません。 Aka は引き続きプロジェクト全体のテストもカバレッジも実行しません —
hatsu:kotoamatsukami と hatsu:byakugan がそれらを mukai で所有します — 赤色の必須チェックでは G5 で停止し、リモートにすでにあるコミットをフォースプッシュしたり書き換えたりすることは決してありません。
ハンドバック。 配線された実行の次: hatsu:mukai — レビュー、影響を受けたテスト、カバレッジ、証拠、PR。それはあなたが呼び出すものであり、この実行はそれを求めません。
1. 呼び出し — およびそれを実行できるユーザー
hatsu:aka
引数はないため、nen parse が所有するものは何もありません — そう述べることが要点であり、省略ではありません。
nen parse <skill> --grammar <テンプレート> --line <テキスト> は文法のために存在します。裸の動詞には文法がなく、パースをエコーできるようにオプションの節を発明することは儀式になります。
呼び出しはメンテナーのものであり、メンテナー自身の言葉または名前によるものです。 2 つの結果があり、両方とも拘束力があります：
- エージェントは決してそれをプロンプトしません。
hatsu:jutaishoがターンの終わりに行うことも、hatsu:spiritual-messageがレポートで行うことも、コンポジットが次のステップとして提供することも、ストップ内の文字付きオプションとしても行いません。レポートは ブランチを公開する準備ができました と言うかもしれません。プッシュしましょうか？ と言ってはいけません。待つように指示された許可を求めるエージェントは、人間の呼び出しをナッジに変換しており、ナッジこそがローカルプレーンのプッシュ規律が防止しようとしているものです。 - 1 回の呼び出し、1 回の実行。 このプッシュに対する
yesは、次のプッシュに対する権限ではありません。実行が開始されたと言い、いつ終了するかを言います。唯一の継続的な呼び出しは、型付きコンポジットのものです（§ 0、2 番目の切り分け：futon または kazaana ライン。そのエフォートは build § 5 を通じて公開します）。スタンドアロンビルドのプッシュは、build § 5 自身の実行スコープの委譲に基づいており、この切り分けには基づいていません。
2. パラメータ — nen/workflow.json、デフォルト値付き
| キー | 用途 | キー（またはファイル）がない場合のデフォルト |
|---|---|---|
branch.base | § 4 のスカッシュと § 5 のキャッチアップの対象となるベース | main |
iteration.lane | § 3 と § 6 が lint するレーン | project.defaultLane |
commits.allowedAttributionTrailers | コミットが保持できる標準的なペルソナ/プレーントレーラー | Hatsu-Agent、Akatsuki-Agent |
commits.forbiddenTrailers | コミットを完全に拒否する属性トレーラー | Co-Authored-By、Claude-Session、Signed-off-by、Generated-by、Generated-with、Reviewed-by を含む |
nen schema check --repo <path> は、このファイルを固定されたビルドで VALIDATE します — ライブで検証され、行は ok nen/workflow.json coverage 80/85/90 (touched), branch '{model}/{persona}/{descriptor}' off 'main', checks: lint と読み取ります。不正なキーは ポインタによる FAIL となるため、このスキルはもはや目視で形状をチェックしません。値を読み取り、適用されたものがデフォルトである場合は常にそのデフォルトを述べます。
欠落している引数または設定項目は尋ねられ、インラインでセットアップされます（missing-argument、missing-configuration; WORKFLOW.md § 4 尋ね、セットアップし、続行）。上記のキーをカバーするデフォルトは使用され述べられ、決して尋ねられません。§ 4 の拒否はギャップではありません。公開済みの歴史の書き換え、禁止されたトレーラー、トランクのプッシュは依然として拒否され、推測して通過することは決してありません。
claude/agents/kurapika.md§ あなたの働き方 からの宣言された変更 — こっそりではなく、名前付き。 現在のエージェント定義は次のように述べています：「メンテナー自身のハーネスが義務付けるトレーラーを超えた AI 属性はありません — 現在はCo-Authored-By:とClaude-Session:… あなたは自分で属性を追加もせず、それらの属性を削除もしません」 そして、最終的なルールは未解決の憲法上の問題であると記録しています。nen/workflow.jsonは、メンテナーが特定のリポジトリに対してその問題に回答する場所であり、このワークフローはそれに回答します：Hatsu-AgentとAkatsuki-Agentは許可され、プレーンごとに 1 つずつであり、他の 2 つは禁止されています。 両者が矛盾する場合、そのリポジトリの独自のcommitsブロックがそのリポジトリに対して優先されます。なぜなら、それは未解決の緊張ではなく、メンテナーの記録された決定だからです。commitsブロックを提供しないリポジトリは上記のデフォルトを取得し、それらは同じことを述べています。これは宣言されたプロセス変更であり、hatsu:futon§ 宣言されたプロセス変更 が自身のものを開示するのと同様に、ここで開示されます。
3. スカッシュ前の lint ゲート
nen wc squash が未公開のコミットでさえ書き換える前に、iteration.lane の宣言された lint 行を実行します：
nen shu lint --repo <path> --lane <iteration.lane> --dry-run
nen shu lint --repo <path> --lane <iteration.lane>
馴染みのないリポジトリでは一度ドライランします。赤色の lint は、歴史が変更される前に実行を終了します。シートが引用されます。このゲートは意図的にスカッシュの前にあります。これは安価であり、aka が複数の有用なチェックポイントを 1 つの赤色のコミットに置き換えるのを防ぎます。これは hatsu:gyo — linting プロセス — であり、スキルではありません。
4. スカッシュ — 未プッシュのコミットのみ
nen wc squash --repo <path> --base <branch.base>
これは 未プッシュのコミットのみを 折り畳みます。リモートにすでにあるコミットはそのまま残り、読み取り専用と見なされます。nen wc squash は、§ 0 で約束された P2 データを使ってこの境界をリモートから取得します。
禁止されたトレーラーがスカッシュ前のコミットに含まれている場合、スカッシュは拒否され、メッセージと共に G5 で実行が停止します：禁止されたトレーラーが <コミット SHA> にあります：<トレーラー>。これは実行の失敗であり、許可を求めるプロンプトではありません。許可/禁止のトレーラーのセットは nen/workflow.json（§ 2）にあります。
ベースブランチがまだローカルにない場合、ここでフェッチされます。branch.base が存在しない場合、スカッシュの前提条件は失敗し、§ 2 のメカニズムを通じてセットアップするよう求められます。
5. キャッチアップ — ベースをその下に持ってくる
スカッシュ後、ベースブランチを最新の状態に追従します：
git fetch origin <branch.base>
git rebase origin/<branch.base>
これにより、ブランチの履歴がリモートのベースの先頭にリベースされ、競合が発生した場合は解決するよう求められます（手動）。リベースが競合により失敗した場合、run は停止し、メンテナーに知らせます。このスキルは競合を自動解決しません。
6. キャッチアップ後の lint — ツリーが変更された場合
リベースによってツリーが変更された場合（新しいコミットが追加された、または競合が解決された）、§ 3 の lint を再度実行します：
nen shu lint --repo <path> --lane <iteration.lane>
ツリーが変更されていない場合（リベースが fast-forward だった場合）、このステップはスキップされます。赤色の lint は § 3 と同じ方法で処理されます：G5、実行停止。
7. プッシュ
git push origin HEAD:<branch-name>
これにより、最終的なツリーがリモートにプッシュされます。force push はありません。公開された履歴の書き換えはありません。プッシュは、§ 0 で定義された範囲内のターゲットブランチに対して行われます。
プッシュがリモートによって拒否された場合（例：fast-forward 以外の更新、保護されたブランチルール）、run は G5 で停止し、メンテナーに拒否の詳細が通知されます。
8. レポート — 実行の要約
すべてのステップが完了したら、次の内容を含む要約を提供します：
- 実行されたアクション（lint 結果、スカッシュされたコミット数、リベースステータス、プッシュステータス）
- 最終ブランチ名
- プッシュされたコミットの SHA
- 発生した警告またはエラー（存在する場合）
- 次のステップへの提案（該当する場合、例：
hatsu:mukai）
9. 停止条件
aka は以下の条件下で停止します：
- G5（致命的エラー）: lint 失敗、禁止トレーラー、プッシュ拒否、予期しない git エラー
- 手動停止: メンテナーによる中断
- 正常終了: プッシュ成功。run は
hatsu:mukaiへのハンドオフで終了します。
aka は、許可されていないアクション（force push、保護されたブランチへのプッシュ、マージ、タグ作成、リリース）に対して 決して 続行しません。