共享政策位置： 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/ 複本不表示缺少政策，且不得觸發重複歸檔。切勿在目標儲存庫中複製或發明第二套政策。
Aka — 分支發布
性質：操控者。 推送在本質上是對共享狀態的 Git 端操作，無論差異是由哪種性質的作者產生。
對其進行 lint，僅折疊未發布的歷史，將基底置於其下，若樹狀結構因此變動則重新 lint，並將該精確的樹狀結構推送到遠端。不建立 PR。不執行專案範圍的測試。
Aka 是本地平面的 第一次人為呼叫。在此之前的一切 ——
hatsu:ren 的回合、hatsu:kokusen 的提交 ——
都在無需詢問的情況下發生，因為它們從未離開過機器。Aka 是工作成果變成他人可以擷取的東西的節點，而這個邊界必須由維護者來跨越。
它不會開啟任何拉取請求。 那是 hatsu:mukai 的執行階段，以及
hatsu:shibari 在其中執行的步驟。Aka 以推送一個分支且僅此而已作為結束，這是刻意為之：推送和 PR 是兩個獨立的決定，將它們合而為一會使其中一個決定變得無法詢問。
0. 獨立入口 — 此技能始終是維護者的決定
Aka 沒有固定的入口點。 § 1 已經說明：整個技能僅在維護者發布呼叫時執行，且
代理永遠不會提議執行它。第一個例外情況，維護者於 2026-09-28 (b) 的裁決
(docs/ROSTER.md § 2026-09-26/27/28 之裁決)：在類型化的
futon 調用中命名此技能的 then 步驟 即為 維護者的發布呼叫 ——
即 mugetsu § 3 定義的先發制人許可 ——
仍然從不提示、從不提議。docs/STANDALONE-ENTRY.md § 6 將其列為報告、鈴鐺、停止選項和複合技能絕不能提供的階段之一 ——
而獨立執行正是一個會讓此類提議看起來像是管道自作主張的場景。
第二個例外情況 — 類型化複合技能的委派發布 —— 依據維護者的裁決
HR-20 (zheref/hatsu#332)，批准了 docs/ROSTER.md § 2026-10-19 的解讀 — 類型化複合技能的委派發布，且未經修改。它建立在兩個已做出的裁決之上：kazaana 的委派者 撰寫並發布 每個排隊的議題（ROSTER § 2026-10-13 之裁決，裁決 1），且在整合分支上的 futon 工作 執行 aka 以發布其自身的工作分支（ROSTER
§ 2026-09-30 之裁決 — En 從不合併，行 當工作停止時)；在堆疊或按議題的形式下，其推送是 futon § 4 → build § 5 的推送。類型化的
futon 或 kazaana 調用 即為對執行作者的每個工作分支的維護者發布呼叫 —— 一個常設的呼叫，而非每個提交一個：
| 類型化 futon / kazaana 行的範圍 | |
|---|---|
| 涵蓋 | 執行佇列中的每個工作：其 初始發布（此技能，在建置委派者或工作階段中 — kazaana § 3；build § 5）以及 每個進行的維護提交和推送 —— 審查修正、跟上進度、審查後的修復（murasaki § 6 內嵌於 mukai 和 en）—— 至執行目標儲存庫和該工作自身的工作分支，通過此技能和 murasaki 的閘門且無任何變更 |
| 不涵蓋 | 另一個遠端或儲存庫、另一個分支、branch.base、強制形式或改寫已發布的提交、標籤、合併、發布。在「涵蓋」列之外，推送的成立與否取決於其擁有技能的自身規則：對於已發布的分支，適用 murasaki § 6；futon § 5 的 整合分支，僅能透過 nen wc publish 推送，絕不透過 aka 且絕不強制（ROSTER § 2026-09-30 之裁決 — En 從不合併）；getsuga § 3/§ 3a 適用於提案分支，§ 4（The cut）適用於標籤。堆疊子分支的重新定位目標是合併計畫的一部分（WORKFLOW.md § 堆疊拉取請求 規則 5；ROSTER § 2026-10-12 之裁決）。若無技能擁有某個動作，則該動作不被執行，並予以回報；僅在該動作是只有維護者才能執行的動作時，它才是 G5 |
| 失效 | 當執行結束時（futon § 10）、遇到暫停、或 G5 終止執行時、或根據維護者的指示失效 —— 絕不因為提交內容變更；某個工作自身的 G5 僅使該工作的範圍失效 —— 絕不影響其他工作 —— 且當維護者回應時，該範圍恢復；G2/G4 合併提示不會使任何範圍失效（如 mugetsu § 3 所述）。恢復、重新啟動或壓縮的工作階段 僅在收到全新的類型化調用時 才持有該範圍，從不從檢查點、執行記錄或摘要中恢復 |
範圍是目的地，而非 SHA。 在同一個儲存庫的同一個分支上出現一個新的提交仍在範圍內；因為提交移動而再次詢問正是 #332 所記錄的失敗。每次交接都攜帶此範圍 —— 從父技能到建置委派者（kazaana § 3）以及之後的每個維護步驟（mukai、en、murasaki）：一個五項事實紀錄 — 調用 逐字引用、推送也依賴的任何維護者回答、儲存庫、工作分支，以及 範圍：初始發布和對此分支的維護推送，直到執行結束。檢查點、執行記錄或
後續交接 絕不會將其縮小為某個確切的提交；若較舊的行記錄有其他說法，則較新的修正 取代 它，而非並列。
該記錄在每次交接中（包括維護交接）都得以保留，且在每個環境中都相同
(zheref/hatsu#529)。本段落不會擴大上述三個行記錄中的任何一個。
選擇器佇列外部的先決條件不屬於類型化行的「涵蓋」範圍：其推送僅依賴於維護者自己授權該發布的措辭（§ 1 的呼叫，以其自己的措辭），引用為第二個事實，針對執行的目標儲存庫 —— 僅批准其準備工作的回答不會授權任何推送，且僅會被詢問一次。空閒執行的整合交付仍屬於 futon § 5 的範疇（上方不涵蓋）；其請求攜帶相同的事實，並引用 futon § 5 作為其權威。需要主機批准的常規推送在請求中呈現該記錄 —— 在 Codex 上，是其支援的審查路由的理由說明（docs/surfaces/codex.md § 發布請求) —— 因此，變更的行動者、工作目錄或提交並無理由再次詢問維護者；主機的決定仍由主機決定。該記錄是供審查者使用的證據，而非自我授予的批准：超出範圍的目的地、受保護的基底、改寫或發布動作將被拒絕或停留在其自身的閘門後，而實際的拒絕則由下一段處理。邊界案例見 docs/ab/publication-authority.md。
主機的拒絕仍由主機決定。 若操作框架的批准層拒絕了範圍內的推送，則該拒絕會與調用和範圍一起引用給維護者，並且僅能透過該主機支援的批准路徑 — 維護者的動作 來解決：維護者在該處的批准，或透過同一路徑重新提交一次，並攜帶其新給出的措辭，與該記錄並列（zheref/hatsu#529）—— 絕不依賴證據重新嘗試，絕不使用另一個命令、路由或環境來執行同一個推送，絕不要求更廣泛的授權，絕不觸碰權限設定。在那裡給出的確切批准，對其自身的動作而言，仍然是有效的收據，且不會擴大任何範圍。
一個代表性的軌跡。 hatsu:kazaana zheref/nen → 委派者的 aka 首次發布了 <model>/kurapika/<slug> 於提交 A → mukai 開啟 PR → en：一個審查發現被修復，kokusen 提交了 B，murasaki 將 B 推送到同一個分支。兩個推送都基於這一個類型化行，且兩者都不需詢問；若 B 被推送到任何其他分支，則超出範圍，其成立與否取決於「不涵蓋」行。
這兩個例外情況保持獨立。 then aka 步驟是第一個例外情況的一次性許可；第二個僅涵蓋複合引擎所進行的每個工作的推送。獨立的 hatsu:aka 保持不變 —— 一次呼叫，一次執行（§ 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 <template> --line <text> 用於文法規則；裸動詞沒有文法規則，而發明一個可選子句以便能夠回顯解析結果將只是一種形式。
呼叫是維護者的行為，以其自己的措辭或指名道姓。 兩個後果，都具有約束力：
- 沒有代理會提示執行它。 無論是
hatsu:jutaisho在回合結束時，還是hatsu:spiritual-message在報告中，或是複合技能將其作為下一步驟提出，或是停止選項中的字母選項。報告可以說 分支已準備好發布；但絕不能說 要我推送嗎？ 一個被要求等待許可卻將其轉化為提示的代理，已將人為呼叫變成了推銷，而本地平面的推送紀律正是為了防止這種推銷而存在。 - 一次呼叫，一次執行。 對這次推送的「是」並不構成對下一次推送的授權。假設執行已開始，並說明何時結束。唯一的常設呼叫是類型化複合技能的呼叫，其範圍由目的地界定（§ 0，第二個例外情況：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> 在固定的建置點驗證此檔案 — 即時驗證通過，該行列印出 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被允許，每個平面一個，而另外兩個則被禁止。 當兩者不一致時，對於該儲存庫，儲存庫自身的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 用一個紅色提交取代幾個有用的檢查點。它是 hatsu:gyo —— lint 流程 —— 而非
…
[因過長而截斷]