共有ポリシーの場所: 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つ目のポリシーをコピーしたり作成したりしないでください。
En — 1つのPRがReadyになるまで保持する円
性質: 操作系 (Manipulator)。 Enが行うすべてのことはボード面向けです — 駆動、報告、呼び出し、監視。Kurapikaが実行するときにそう言います。サイクルが彼を変更自体に送り返すとき — コード修正を必要とするレビュアーの指摘 — その修正のモードは変更自体のモード（強化系、具現化系、変化系）であり、そのサイクルに向けて声に出して命名され、その後で返却されます。
このPRに留まれ: それを報告し、現在の最新のチェックとレビューをすべて監視し、検証済みのReadyに導き、人間のゲートで1回呼び出し、最大N回のアクティングサイクルの後に停止せよ。
Enはローカルプレーンの最後の複合体であり、PRが開かれた瞬間を超えて注意を維持する必要がある唯一のものです。$mukaiはこのハンドオフを提供することで終了します — それ自体を nen/workflow.json → mukai.autoEn（裁定 2026-09-28）の下でのみ開始し、そこからPRはEnに属します — そして autoEn パスのみで依然としてアクティブなユーザーターンは、提供からの型付けされた開始がそれ自体のターンとなります — Sharingan がReadyを証明するか、具体的なブロッカー/上限/終了状態/キャンセルがEnの実行を終了するまで。マージはメンテナーの後の行為であり、§5 の記録されたFutonデリバリー例外を除きます。この実行は収穫もクリーンアップもしません。 Enが完了したとき、呼び出し元はピッカーを通じてラップアップを提供します（cleanup §2、行 wrap-up; 裁定 2026-10-13）— cleanup §2 の2つの前提条件（HR-366）の下でのみ; §5 のプロンプトでのReady PRはどちらも満たしません: $cleanup（必須）と、それに加えてオプションの $third-hand — 別個のスキルであり、このファイルのプロトコルが戻った後に開始され、Enのステップとしては決して開始されません。
このファイルは構成します。再指定はしません。 以下のすべてのステップは別のスキルのものであり、名前が付けられリンクされており、その手順、終了コードの反応、拒否、および残差はそこにあります。もしここにあるルールが実際にはそのスキルのものである場合、それは間違ったファイルにあります — それが作成された場所で読んでください。なぜなら、2箇所に再記述されたルールはそのうちの1つで乖離するからです。
真にEn自身のものは、上限、監視の形状、およびセッションの終わりの境界です。 これら3つは§2、§6、§7であり、このファイルが何かを主張する唯一の場所です。Third-Handはその境界内にはありません。
1. 呼び出し
P1 — この実行は $ten en で開始する (ten §6 は、このフェーズの欠落している前提条件を自身の名前でキャッチアップします; この実行が呼び出すフェーズは自身のものをスキップします)。
$en [on <CODE>#<N>]
$mukai によって句なしで mukai.autoEn の下で開始 — PRはステップ8が開いたばかりのものです — $getsuga §3 によって、それが開いたばかりのリリース提案のために開始 — （そこではenはステップ1～5を実行し、その引用された評決をgetsugaに返します; ステップ6のベルは鳴らされません。なぜならgetsuga §3aがそのPRのマージだからです）、$futon のイシューごとのチェーンによって、その努力が開いたPRのために、またはその統合→メインPRのために（futon §5は統合ブランチにPRを開きません; そこではローカルにマージします）、またはメンテナーによって、すでに開いているPRを指定して開始されます（mukaiの提供行）。セッションが開いたり開かせたりするすべてのPRがこの実行を通じて、または評決を引用してメンテナーに到達するというルールは、docs/PROCESS.md § フェーズの報告（zheref/hatsu#103）にあり、引用されており、再記述されていません:
nen parse en --grammar "on [<ref>]" --line "<呼び出し文字列、$en プレフィックスを除く>"
v0.3.0 (docs/ab/en.md § 2.1) でライブ検証済み: on HA#41 → ref: HA#41 終了コード 0、そして裸の on は句が存在しないものとしてパースし、こちらも終了コード 0。句はリテラルの後ろにアンカーされています。その理由は $spiritual-message §1 が記録している通りです — 単独の括弧付きスロットはテンプレートで拒否されます。
空行は拒否され、それが複合体がまったくパースされない理由です。 ライブ検証済み:
--line ""は終了コード2で 「行はリテラル 'on' で開始する必要があります — それが<ref>を導入するものです」。アンカー付きのオプション句はそのアンカーを必要とします; 「句なし」と「空行」は異なる入力であり、最初のものだけがパースされます。したがって、autoEnの下のmukaiはPRを直接引き渡し、nen parse enをまったく呼び出しません — 誰も入力しなかった行のパースをエコーすることはパフォーマンスであり、""を与えると意味のない拒否が生成されます。パースは、メンテナーが句を入力したとき、そしてそのときのみ実行されます。
欠落している引数または設定項目は、インラインで尋ねられ設定されます（missing-argument、missing-configuration; WORKFLOW.md §4 尋ね、設定し、続行する）: 終了コード 2 で終了するメンテナーの行、またはセッションがPRを保持していないのにPRを指定しない行は、セッションのオープンPRをピッカーで提供し、回答で再開するトリガーであり、実行の終了ではありません。
コードを最初に一度解決し、後のすべての呼び出しのためにスラッグを保持してください — 決して2番目の方法で再導出しないでください（claude/agents/kurapika.md § あなたの働き方）:
nen repo resolve <CODE> --repo <ターゲットリポジトリ自身のチェックアウトへのパス>
nen ref format --code <CODE> --kind PR --number <N>
クローズまたはマージされたPRは、そのPRに起こったこととともに即座に実行を終了します。 着地させるものは何もありません。
ヘッドがすでに公開されているオープンPRは、すべての継続においてEnに留まります。 そのブランチがPRベースより遅れた場合、またはレビュー修正が公開を必要とする場合、Enの現在のツリーエビデンスステップと $murasaki のガード付きfast-forwardプッシュを実行します（§3 および murasaki §6）。公開されたブランチを $aka のスカッシュに通さないでください。最初の公開は、それを呼び出すワークフロー（直接のAka呼び出しでもFutonのような複合体でも）によってすでに運ばれている承認に従います。Enは依然として§5の別個の人間マージゲートで停止します。例えば、PR #274 は #273 が main を進めたときにすでに b5fddea で公開されていました; そのキャッチアップマージはその公開された祖先を保持し、Murasakiは検証済みの子孫 5de39c5 をプッシュしました。
この複合体が呼び出すフェーズは、自身の ## 0. スタンドアロンエントリー セクションをスキップします。 docs/STANDALONE-ENTRY.md は、任意のチェックアウトに手動で入力されたフェーズのための契約です; ここから到達したフェーズは、この実行からP1～P4を継承します — ウォームアップ、オリエンテーション、変更セット、およびすべての派生引数 — それらを再導出すると、この複合体がすでに解決した質問に対して2番目の答えを生成することになります。各フェーズは、代わりにどの複合体がそれを保持しているかを述べます。
2. 上限 — デフォルトではなく文法
Enは行動します。 ステップ2と4は駆動します; 新しいレビュー指摘を見つけるサイクルは変更に戻り、修正をプッシュします。それによりenはループペアの変更を加える半分となり、$izanagi の全規律が適用されます: 書き込むループには境界が必要であり、読み取るループには不要であり、境界を文法の一部にすることは、それが決してデフォルト化、継承、または忘れられることがないことを意味します。
| キー | ファイル | 使用目的 | キー（またはファイル）が存在しない場合のデフォルト |
|---|---|---|---|
monitor.maxCycles | nen/workflow.json | 上限 — アクティングサイクル（§6）の数 | 20 |
monitor.pollSeconds | nen/workflow.json | 観測間の間隔、--interval-ms として | 300 (→ --interval-ms 300000) |
branch.base | nen/workflow.json | §5がプロンプトするベース。ステップ3はここからキャッチアップし、「遅れている」はPR自身の baseRefName（gh pr view <N> --json baseRefName）に対して測定され、これはenがプロンプトするすべてのPRの branch.base です | main |
reports.dir / .sections / .retain | nen/workflow.json | ステップ7のファイル — backlog-board §3のキー | Reports / 必須、デフォルトなし（WORKFLOW §2 → reports）/ final-only |
notifications.rungs / .sound | nen/workflow.json | ステップ6の段 — $jutaisho のキー | ["push","os","sound"] / Glass |
サイクル1の前に、上限は欠落を拒否する動詞を通じて明確にされます:
nen parse izanagi "take <CODE>-PR-#<N> to its human gate until it is Ready up to <monitor.maxCycles>"
v0.3.0 (docs/ab/en.md § 2.2) で両方向でライブ検証済み:
$ nen parse izanagi "take HA-PR-#41 to its human gate until it is Ready up to 20"
task: take HA-PR-#41 to its human gate
until: it is Ready
cap: 20
exit=0
$ nen parse izanagi "take HA-PR-#41 to its human gate until it is Ready"
nen: no 'up to <N>'. Izanagi is the MUTATING half of the loop pair and the cap is required grammar,
never defaulted or inferred -- an invocation without it is refused rather than run once 'to see'.
try: take HA-PR-#41 to its human gate until it is Ready up to <N>
exit=2
値は monitor.maxCycles から取得されます; 要件は文法から取得されます。 これらは2つの異なるものであり、その区別が要点です: ファイルは数値を提供し、動詞は数値なしでは実行を拒否します。monitor ブロックが欠落しているリポジトリは、声に出して述べられた 20 を取得します — それは境界のない監視を取得しません。なぜなら「ファイルが何も言わなかった」というケースは、まさに継承され忘れられたデフォルトが危険な状況だからです。
nen
0.7で廃止: 手動でのアクティングサイクルカウントすべてのアクティングサイクルは行動する前に主張され、上限は主張が拒否されることで強制されます —
izanagi§3 の廃止、全体を継承:git rev-parse --path-format=absolute --git-common-dir # <common>、エフォートワークツリー内 nen loop iterate --id en-<CODE>-<N> \ --line "take <CODE>-PR-#<N> to its human gate until it is Ready up to <monitor.maxCycles>" \ --repo <common>終了コード
0はiteration <n>/<cap>と残り回数を出力します — 動詞自身の言葉は iteration であり、enのサイクルはそれが主張しているものです; 終了コード1が上限そのもの であり、§6の上限超過行で実行を終了し、呼び出しはnen自身の拒否で名前が付けられます。--lineは上記nen parse izanagiがエコーしたのと同じ文字列であり、すべての主張で再述されるため、monitor.maxCyclesは実行中に静かに引き上げることができません: 異なるNを持つ主張は両方の行を名前として終了コード2になります（正確にこの形状に対してライブ検証済み —up to 3実行中、up to 20主張 —docs/ab/izanagi.md§ nen 0.7 で廃止）。
--idはセッションではなくPULL REQUESTです、そしてそれは述べる価値のある結果を持つ決定です: 台帳は.nen/loop/en-<CODE>-<N>.jsonであり、git共通ディレクトリの下にあるため、セッション（§7）とクリーンアップによって削除されるエフォートワークツリーより長持ちします（docs/ab/en.md§ 上限はワークツリーより長持ちする）、したがって 同じPRに対して再呼び出しされた$enは、サイクル1から再開するのではなく、同じ上限を再開します。それが「このPRをReadyにするための20のアクティングサイクル」の正直な読み方です — セッション境界リセットがもたらす上限は誰も持たない上限です。準備ドライブが本当に終了したとき — Ready、クローズ、またはゲートでメンテナーに引き渡された —nen loop iterate --id en-<CODE>-<N> --line "<同じ行>" --release "<理由>" --repo <common>で台帳を閉じます; 上限に達したループは常に解放でき、その後の新しい上限は、意図的に選択され声に出して述べられた新しい--idであり、再入力された行ではありません。
上限は目標ではなく天井です。 到達することはReadyに到達できなかったことであり、そのように報告されます: まだ真ではないこと、そして次のサイクルが何をしていたか。izanagi §4 のルール、変更なし。レビューラウンドポリシーは $sharingan §6 のものであり、そこに一度だけ記述され、ここで引用され、決して再記述されません:
- 1回のCopilotラウンドは
$hantenが落ち着いた後に要求され、決してそれより前ではありません。 - 到着は修正され、未払いのラウンドは sharingan §6 の2つの境界内でのみ尋ねずに再要求されます（
round_policy.maxRounds要求、round_policy.minRounds解決; 行cap-reached）、その後enは監視を続けます; どちらかの境界に達した場合は§6の5番目の停止です。 - 再要求の前に、
nen wake verify --repo-slug <owner/name> --now <ISO> --author-pattern <メンテナーログイン> --runは飲み込まれた実行を一度再駆動します（action_requiredまたはstartup_failureで実行されなかったもの）; Copilotボットによるaction_required実行は再試行できず、そのように報告されます。次にno-op同期ガード: 最後にレビューされたヘッドより先のコミット数をカウントし（git rev-list --count <reviewed-head>..HEAD、読み取り専用）および差分統計; レビュー可能な変更がゼロの場合、要求はありません。 - Copilotはすべてのプッシュを自動レビューするため、上限は到着ではなく要求を管理します; 上限を超えた到着は依然として修正され、そのスレッドは解決されます。
最大値を超えると、実行は未Readyでボードとともに終了します。どちらもG5ではありません。nen/workflow.json → monitor.maxCycles はenのアクティングサイクル上限であり、異なる数値です。
3. 実行、順に
| # | ステップ | それを所有するスキル | タイミング |
|---|---|---|---|
| 1 | ランディングレポート | $spiritual-message as landing | 一度、開始時 — 00–07 に加えて 08 PR本文 と 09 準備状態。このEnがmukaiによって開始された場合（autoEn）、または同じ席でその提供から入力され、新しい人間の要求がない場合、00 はまだそのmukai要求に答えます |
| 2 | 駆動 | $sharingan | 最初のブロッキング条件（存在しない場合、またはCIが完了していない場合）で呼び出されます。sharinganはレビューを管理し、CIを監視し、結果をEnに報告します |
| 3 | キャッチアップ | $murasaki | PRブランチがベースより遅れている場合、またはレビュー修正のプッシュが必要な場合。murasakiはガード付きfast-forwardプッシュを実行します |
| 4 | 通知 | $jutaisho | ステップ2で新しいレビュー結果がある場合、または上限に近づいている場合。jutaishoは設定された段に基づいて通知を送信します |
| 5 | 人間ゲート | メンテナー（Enはプロンプトのみ） | PRがReadyになったとき。Enはメンテナーにマージを促しますが、マージは行いません（§5のFutonデリバリー例外を除く）。メンテナーが別のアクションを選択した場合（例: さらなる変更）、Enは監視を続けます |
| 6 | 上限チェック | $izanagi（継承） | 各アクティングサイクルの開始時。上限に達した場合、実行は未Readyで終了し、そのように報告されます |
| 7 | 最終報告 | $backlog-board | 実行の終了時（Ready、上限超過、キャンセル、または中断）。backlog-boardは reports.dir 指定された場所に概要ファイルを作成します |
4. 継続と状態
Enは中断可能です。 実行が中断された場合（例: タイムアウト、手動キャンセル）、同じPRに対して $en を再呼び出しすると、台帳がリセットされない限り（§2 廃止参照）、前回の停止箇所から続行され、上限が維持されます。
状態は git common dir の下の nen/loop/en-<CODE>-<N>.json に保持されます。 このファイルには以下が含まれます:
- 現在のサイクル番号
- 上限
- 最後の既知のPR状態（ヘッドSHA、CIステータス、レビューステータス）
- 発行された通知のリスト
このファイルを手動で編集しないでください。 削除すると、上限がリセットされ、Enは最初からやり直します。
5. マージ
En自身はマージしません。 代わりに、PRがReadyになった時点でメンテナーにプロンプトを出します。§6の上限に達するか、中間状態（さらなるレビューが必要など）のためにEnが終了する場合、PRは開いたままメンテナーに返されます。
例外: 記録されたFutonデリバリー。 $futon が所有するスタックデリバリー（futon §5に記録）は、Nenの制限付きガード（nen/workflow.json → futon.autoMerge）の下でEnによってマージされる場合があります。この場合、Enはマージを実行し、結果を報告し、実行を終了します。この例外は、Futon所有のPRにのみ適用され、明示的な設定が必要です。
6. アクティングサイクル
アクティングサイクルは、Enが1回以上の能動的アクションを実行する期間として定義されます:
- PRのステータスのポーリング
- レビューの要求または再要求
- キャッチアップのための変更のプッシュ（murasaki経由）
- 通知の送信（jutaisho経由）
- 人間ゲートでのプロンプト
静かなポーリング（ステータスの変化なし）はサイクルを消費しません。 サイクルは、Enが上記の能動的アクションのいずれかを実行した場合にのみ消費されます。上限 monitor.maxCycles は、アクティングサイクルの最大数を定義します。上限に達した場合、Enは未Readyで終了し、backlog-board報告書を生成します。
7. セッションの終わり
Enの実行が完了すると、呼び出し元（例: mukai、メンテナー）が制御を取り戻します。Enは結果を報告し、元の呼び出し文字列と置き換わるテキストとしてラップアップを提供します。ラップアップは以下を含みます:
$cleanup（必須）: 努力ワークツリーと中間成果物のクリーンアップを処理します。$third-hand（オプション）: 追加の手動ポストプロセッシングが必要な場合に利用できます。
Enはクリーンアップを実行しません。 それは呼び出し元の責任です。Enは、通常のシーケンスの一部として、または例外状況（上限超過、キャンセル）によって、明確な終了点に達した場合にのみ終了します。
改訂履歴:
v0.3.0: 初期バージョン、nen parse統合と上限文法を検証。v0.7.0(予定): 手動サイクルカウントの廃止、izanagiループ機構への移行。