共有ポリシーの場所: 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つ目のポリシーをコピーしたり、新たに作成したりしないでください。
Ren — 1リクエスト、1ターン、毎回
固定モードはありません。 Renは合成実行です。モードは リクエスト に応じて決まります —
製品コードの場合は Enhancer、カノンの場合は Conjurer、機械の場合は Transmuter — ターン中保持され、応答に名前が付けられ、ターンの報告手順が実行されている間は Manipulator も併記されます。実行中のモードを名前で示し、いつ切り替わり、その理由を述べ、2つのモードを1つのヘッダー下で混在させないでください（claude/agents/kurapika.md）。
リクエストを受け取ってください。これが最初の場合はウォームアップし、それを作成し、証明してコミットし、起動を処理し、 レポートを見せて、1回ベルを鳴らしてください。その後待機します。
Renはローカルプレーンにおける 通常作業の形 です。バッチランナーでも監視役でもありません。1回の呼び出しは1つのリクエストであり、1つのリクエストは1つのターンです。 ループの仕組みは、次のリクエストが次のターンを開始し、ウォームアップステップは既に消費されているというものです。
このファイルは合成します。再仕様化はしません。 以下の各ステップは他のスキルのものであり、名前とリンクが示され、その手順、終了コードの反応、拒否、および残留物はそこに存在します。もしここにそのスキルに本当に属するルールを見つけた場合、それは間違ったファイルにあります — それが作成された場所で読んでください。なぜなら、2か所で言い換えられたルールはそのうちの1か所でずれるからです。
1. 呼び出し
P1 — この実行は $ten ren で開始します（ten § 6 はこのフェーズの不足する前提条件を自身の名前でキャッチアップします。この実行が呼び出すフェーズは自身のものをスキップします）。
$ren <リクエスト> [--profile fast|standard|thorough]
nen parse ren --grammar "<request> [--profile <profile:fast|standard|thorough>]" \
--line "<リクエスト。$ren プレフィックスを除いたもの>"
profile:（句が存在しない場合） は profile.default（§ 2a）を意味します。リクエスト内の「fast turn」または「thorough turn」という単語も同じオーバーライドとして読み取られます。
v0.3.0（docs/ab/ren.md § 2.1）で検証済み：リクエスト行は request: <行全体> として終了コード 0 でパースされ、空行は終了コード 2 で拒否されます — 「 は必須ですが、行がそれを提供していません」 — 修正された行が出力されます。リクエストのないターンがセッションが最後に行っていたことから推測されることはありません — 自由テキストとして要求されます：リクエストはメンテナーの言葉です（行 missing-maintainer-choice、nen stop answer を通じて記録、docs/WORKFLOW.md § 4 メンテナーの言葉は決して派生されません）。そのため、セッションが提案する読み取りはすべて参考としてリストされ、どれも星印が付けられず、ピッカーオプションにもならず、ターンはメンテナーが入力した内容で実行されます。
Renは明示的な呼び出しだけでなく、デフォルトの形状でもあります。 nen/workflow.json がこのループを記述しているリポジトリでは、メンテナーからの通常のリクエスト は renターンです。最初のターンでそのことを述べて、最後のレポートとベルで誰も驚かないようにしてください。
2. ターン、順に
| # | ステップ | 所有するスキル | なぜここにあるのか |
|---|---|---|---|
| 1 | ウォームアップ | $breath | すべてのエントリで分離をバインド/再検証 WORKFLOW § ワークツリーの場所 に従い、Tenのキャッチアップや変更の前に行います。そのチェックアウトで新しいエフォートごとに1回、新しいブランチをウォームアップし証明します — 観測されたフック拒否（HR-374）に対するセッション自身のハーネスワークツリー。明示的な継続は、検証済みのエフォート所有ワークツリーのみを再利用します。ベースが赤い場合は、作成前の G5 です。その憲法チェック（breath § 4a）の競合句も同様であり、このステップの台帳エントリに記録されます |
| 2 | 変更を作成 | $rasengan | メンテナーが要求したものを、このリポジトリが宣言するスタック上に書きます：編集、それに伴うテスト、その規約が負うドキュメントとチェンジログ — 宣言された iteration.checks を作成者自身のフィードバックとして、作業が目の前にある間に実行します |
| 3 | 検証してコミット | $kokusen | すべての安価な iteration.checks 動詞と、完成した ツリーに対する宣言されたフォーカスされたテストを実行し、赤は拒否されます。その後トリアージ、フラグが立てられたものについての質問、1つの整形されたコミット — ローカルのみ |
| 4 | 起動 | $amaterasu | 分離されたエフォートがドライランのコマンドを報告し、core launch deferred; explicit maintainer call required を記録し、その後 尋ねることなく 続行します。シリアルであっても。ターゲットがない → no launch target declared; skipped。コア起動は、作成や配信をバインドされたワークツリーの外に移動させることはありません |
| 5 | レポート | $spiritual-message as turn | ページ：達成事項、課題、未配信、アーキテクチャ、スクリーンショット、正確な起動コマンド、決定事項 |
| 6 | ベル | $jutaisho（§ 1 がページの依頼がストップを構成するかどうかを決定します） | ワークフローが宣言するラング — そして本当にストップが必要な場合のみストップ |
ステップ2は変更そのものであり、2026-09-10以降、半分の番号付けは廃止されました。 この表は以前、どのスキルにも所有されていないステップ
1.5— 「作業」 を、ビルド と呼ばれるステップ2の横に持っていました。ステップ2はrasenganを 「ビルドコマンドを実行する」 ではなく 「ものを作成する」 として読み取っていました。メンテナーの裁定（docs/ROSTER.mdHR-55）により決定：rasenganは作成フェーズそのものです。したがって、作業にはスキルがあり、6つの整数は再び6つのスキルであり、コミット前のコンパイルはツリーをステージングするフェーズに属します。
順序は5つの場所で重要であり、それらの5つだけがrenが主張するものです：
- 1は2の前 — 未検証のベースでの作成はありません。 Breathは
origin/<branch.base>の新しくフェッチされた先端からブランチをカットし、宣言されたチェックをそこで証明します。そのため、変更の最初の行はすでにビルドが既知のツリーに着地し、誰かが見る最初の赤はこのエフォートが引き起こしたものです。ベースの先端が赤い場合は、行が書かれる前の G5 ストップであり、このエフォート内部で修復されることはありません。同じことがbreath § 4aの憲法チェックにも当てはまり、そのゲートはbreath § 6 が述べています（WORKFLOW.md§ 憲法チェック）。 - 2は3の前 — このターンで作成され、その中で検証されなかったものはコミットされません。 Rasenganは変更を書き、自身の内部ループの正当性を保ちます。その後kokusenは 完成した ツリーに対して宣言されたチェックを実行し、赤でコミットを拒否します。2つの実行は重複ではありません：ツリーは作成者の最後のチェック以降に書かれたすべての行で移動するため、コミットが依存できる唯一の実行は、インデックスを保持するフェーズによって行われたものです。ターンが反復する場合（書き込み、チェック、再書き込み）、それはステップ2がそれ自身と反復していることであり、ステップ3は1回だけ入力されます。
- 3は4の前。 起動処理はコミットされた結果に従います。分離はコア起動を許可しません。延期されたコマンドは、このエフォートのツリーの実証ではありません。
- 4は5の前。 レポートは、延期されたドライランコマンドと実際に実行されたargvを区別します。
- 5は6の前。 ベルはレポートのリンクを運びます。ページが存在する前に鳴るベルは、メンテナーを何もないところに送ります。
この複合が呼び出すフェーズは、自身の ## 0. スタンドアロンエントリ セクションをスキップします。 docs/STANDALONE-ENTRY.md は、任意のチェックアウトに手動で入力されたフェーズのコントラクトです。ここから到達したフェーズは、この実行から P1～P4 を継承します — ウォームアップ、オリエンテーション、変更セット、およびすべての派生引数 — そしてそれらを再導出すると、この複合が既に解決した質問に対して2つ目の答えを生成することになります。各フェーズは、代わりにどの複合がそれを保持しているかを示します。
ステップ1内で、分類されたエフォートごとに1回、$direct が実行されます — これはリクエスト内で問題（<CODE>#<N>）または既にラベル付けされたテキスト分類を指定するエフォートに対して、このセッションの --surface、--model、--effort（ハーネスが隠している場合は unread）を使用して、build § 2b とまったく同じように実行されます。その § 6 は比較と1回の質問を所有し、入力された $ren はすでにここで作業する決定であるため、決してブロックしません。その回答 B はこの ターン を終了しますが、ループは終了しません：ステップ5と6は依然として実行され、レポートは再開行を指定します。job/ ラベルのないエフォートは undirectable、1行で、ターンは続行します。これは7番目のステップではなく、独自の順序を主張しません：ウォームアップ内で読み取り、最大1回尋ね、何も作成しません — そしてその § 7 の公開ステップは ここでは実行されません：Renはマシンを離れることができないため（§ 3）、評決はレポートとローカル台帳に残り、direct.publish は build、file（提出後）、またはスタンドアロンの下でのみ動作します。
ウォームアップはエフォートごとに1回実行されます。チェックアウトの選択はすべてのエントリでチェックされます。 後のターンとPRフェーズは、$hatsu_root/docs/WORKFLOW.md § ワークツリーの場所 に従って、ステップ2またはキャッチアップの前に、バインドされた絶対エフォートパスを再検証します。パス、元のプロンプトの免除ステータス、およびBreathがウォームアップしたのか単に再検証したのかを報告します。継続はバイパス分離を行いません。
呼び出し元が明示的に現在のエフォートを継続しない限り、新しいリクエストは新しいエフォートです。 以前のエフォートからのクリーンな機能ブランチにいることは継続ではありません（zheref/hatsu#60; $breath § 2a）。Breathは依然として実行され、構成されたベースをフェッチし、新しくレンダリングされたブランチをカットします。再利用は、明示的な「continue」/「same effort」/「on this branch」の場合、またはこのセッションでステップ1がすでに この ブランチをカットしたループのターン2+の場合のみです。
このエフォートの後のターン、または $mukai が $hanten に再入する場合、同じサイクル台帳を再利用します — .nen/hanten/<branch-slug>.cycle.json。修復はレビュー担当者のカウントをリセットしません。Breathが新しいブランチをカットすることだけが新しいサイクルです（zheref/hatsu#63; hanten § 2a）。
2a. プロファイルとフェーズ台帳
nen/workflow.json 内の profile.default がターンを形成します（存在しない場合は standard）。§ 1 の --profile がそれを上書きし、profile.allowed 外の値は許可リストをピッカーのオプションとして再度尋ねられ、ターンの最初の行が実行中のプロファイルを指定します。
| プロファイル | § 2 での変更点 |
|---|---|
fast | ステップ1はバインディングを検証します。ウォームアップは依然として1回実行されます。ステップ2と3は宣言されたとおり。ステップ4はスキップされ、起動行は deferred by profile fast; isolation still requires an explicit maintainer core-launch call。ステップ5は --variant turn-fast をレンダリングします |
standard | 今日のターン、上の表のとおり |
thorough | standard に加え、ステップ3の後、kotoamatsukami の影響を受けるスイートがすべてのターンで実行されます |
プロファイルは、どのステップが実行され、ステップ5がどのバリアントをレンダリングするかを決定します。ステップ内で何が起こるかを決定することは決してありません。 ステップ2と3は、すべてのプロファイルの下で各自のスキルが述べるように実行されます。fast の下では影響を受けるスイートは実行されません（それらは mukai のものであり、そこでのステップ4です）。thorough の下ではkotoamatsukamiの影響を受けるスイートがステップ3の後に実行され、renはそのスキルの3番目の呼び出し元です。起動はスキップされ、移動されません：mukaiには起動ステップがなく、amaterasu § 1a はスキップされた起動がどのように扱われるかを述べています。カバレッジはrenプロファイルによってキャプチャされません。それは byakugan のものであり、mukaiにあります。
ランディング（mukai）は常に thorough で実行されます、その前のターンが何を指定していても。
すべてのステップは1つの台帳エントリです（WORKFLOW.md § エフォートの台帳 がメカニズムを所有します。renのものであるのは、どのステップといつ行うかです）。ステップの前に、nen phase begin --effort <branch> --phase <step-name> --surface <s> [--model <reported-model>] --dial <level> を実行します。モデルがハーネス報告された提供IDである場合は、--note "model-kind=served; registry alias <alias>" を追加します（WORKFLOW § エフォートの台帳）。最初のフェーズで nen session record をハーネスのタイトル/IDが公開されているときに記録し、セッションごとに1回行います。ステップの後に、nen phase end --effort <branch> --phase <step-name> --exit <code> を実行します。これにより、.nen/phases/<effort>.json に、フェーズごとに1つのタイムスタンプ付きエントリが含まれます（拒否されたステップも含む）。ステップ1の end は、breath § 4a の記録を --note として運びます。これはステップ1が開始したノートと組み合わされます。なぜなら end --note がそれを置き換えるからです（スクリプトの --begin-note; WORKFLOW § 憲法チェック、ステップ3、5、6がフォームを所有します）。チェックはそれ自体のエントリではないため、6つのステップは6つのエントリのままです（HR-58）。使用量エントリはステップ5で記録されます：nen usage record --effort <branch> --surface <s> [--model] --dial <level> [--input] [--output] [--cache-read] [--cache-write] [--minutes] をサーフェス自身のコスト読み取りから、何も公開しないサーフェスでは --not-reported を付けて実行します。
再開されたエフォートは、書き込む前に読み取ります（zheref/hatsu#444、zheref/hatsu#445; nen 0.28、ピン）。ブランチに既にフェーズ台帳またはPRがあるエフォートは再開です：まず、PRが存在する場合 — オープンなもの：後継の番号、ベース削除が閉じたPRではありません（en § 6） — nen pr ledger read --target <owner/name> --pr <n> --effort <branch> --repo <checkout> --json を実行し、nen phase show がローカル台帳を見つけない場合のみ --restore を追加します。次に nen phase show --effort <branch> --json を実行します。WORKFLOW § エフォートの台帳、永続スライス が評決と1つのスキップ行フォームを所有します。スキップされた breath エントリのノートはステップ2の前に読み取られます（WORKFLOW § 憲法チェック、ステップ7）。フェーズごとに、順に：終了コード 0 で終了 → **…
[翻訳のため省略]