共享策略位置： 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 端操作，无论 diff 是由哪种性质撰写的。
对其进行 lint，仅折叠未发布的历史，将基准分支置于其下，如果这样移动了树则重新 lint，然后将该确切的树放到远程。没有 PR。没有项目级测试。
Aka 是本地平面上的 第一个人类调用。在此之前的一切——
hatsu:ren 的轮次，hatsu:kokusen 的提交——都会在无需询问的情况下发生，因为它们都不会离开机器。Aka 是工作成果变得可以被他人获取的地方，而这个边界需要维护者来跨越。
它不打开任何 Pull Request。 那是 hatsu:mukai 的运行，以及 hatsu:shibari 在其内部执行的步骤。Aka 以推送一个分支而结束，别无它物，这是刻意为之：推送和 PR 是两个决策，将它们折叠在一起会使得其中一个决策变得无法被询问。
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 将其列为报告、铃铛、停止的选项以及复合体不得提供的阶段之一——而独立运行正是这种提议看起来像是流程自作主张的地方。
第二个例外——类型化复合体委托的发布——维护者的裁决 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）以及 每次维护提交和传递它的推送——审查修复、catch-up、经过审查的修复（在 mukai 和 en 内部的 murasaki § 6）——到运行的目标仓库以及该工作自己的工作分支，未经修改地通过此技能和 murasaki 的门控 |
| 未涵盖 | 另一个远程或仓库、另一个分支、branch.base、强制形式或重写已发布的提交、标签、合并、发布。在“涵盖”行之外，推送成功与否取决于其所属技能的自身规则：对于已发布的分支，参见 murasaki § 6；对于 集成分支，仅使用 nen wc publish 推送，从不通过 aka 且从不强制（ROSTER § 2026-09-30 的裁决——En 从不合并）；对于提议分支，参见 getsuga § 3/§ 3a；对于标签，参见 § 4（剪辑）。堆叠子分支的重新定位是合并计划的事（WORKFLOW.md § 堆叠 Pull Request 规则 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 步骤是第一个例外的单次 go；第二个例外仅涵盖复合引擎进行的按工作推送。独立的 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在报告中，不是复合体将其作为下一步提供，也不是停止中的字母选项。报告可以说 分支已准备好发出；但不能说 我该推送吗？ 一个被要求等待许可却将其转化为催促的代理，已经将人类调用变成了一个“推动”，而本地平面的推送纪律正是为了防止这种情况。 - 一次调用，一次运行。 对此推送的
yes不是对下一次推送的授权。假设运行已开始并在结束时说明。唯一的长期调用是类型化复合体的，其范围由目标限定（§ 0，第二个例外：futon 或 kazaana 行，其工作通过 build § 5 发布）；独立构建的推送依赖于 build § 5 自身运行范围的委托，而不是此例外。
2. 参数 —— nen/workflow.json，附默认值说明
| 键 | 用途 | 当键（或文件）不存在时的默认值 |
|---|---|---|
branch.base | § 4 的压缩和 § 5 的 catch-up 所依据的基础 | main |
iteration.lane | § 3 和 § 6 进行 lint 的通道 | project.defaultLane |
commits.allowedAttributionTrailers | 提交可能携带的规范角色/平面 trailers | Hatsu-Agent, Akatsuki-Agent |
commits.forbiddenTrailers | 直接拒绝提交的 attribution trailers | 包括 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 的拒绝不是缺口：重写已发布的历史、禁止的 trailer 以及推送主干分支仍然会被拒绝，绝不会被猜测过去。
声明的对
claude/agents/kurapika.md§ 你如何工作 的更改——已命名，并非悄悄引入。 今天的代理定义写道 “除了维护者自己的框架强制要求的 trailers 之外，没有 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 过程——而不是
…
[翻译截断]