Skip to content

cross-refactoring: ホストが agy か kiro だとラウンド 1 の適用担当がホストになるのに、手順書は「ホストが最初に適用しない」と書く #804

Description

@takemi-ohama

何を見つけたか

cross-refactoring の手順書と共通層の説明は「ラウンド 1 は参加者の 2 番目から始まるため、ホストが最初に適用する形にならない」と書く。ホストが agy か kiro のときは成り立たない。

参加者はランタイムの固定の順(claude / codex / agy / kiro)に並び、適用の輪番はラウンド 1 で 2 番目の者を選ぶ(impl_assign(1, runtimes) は runtimes[1])。既定の参加者で試すと次のとおりである。

ホスト 既定の参加者 ラウンド 1 の適用担当
claude claude / codex / kiro codex
codex codex / kiro kiro
agy codex / agy / kiro agy(ホスト)
kiro codex / kiro kiro(ホスト)

どこで見つけたか

PR #803(P7 の確定仕様)の収束レビューで codex が指摘し、kiro が反証の段でコードから再現した。同じ主張は次にある。

  • plugins/ndf/skills/cross-refactoring/SKILL.md:135
  • plugins/ndf/scripts/lib/assignment.py:286(impl_assign の docstring。例はホスト claude だけ)
  • plugins/ndf/skills/cross-refactoring/tests/test_assignment.py:94、tests/test_rounds.py:38(テストはホスト claude だけを確かめる)

なぜこの変更の範囲外なのか

PR #803 は確定仕様だけを書く Pull Request で、手順書・共通層・テストを変えない。確定仕様の 2 つの文書は、実装の振る舞いどおりに「ホストが claude / codex のときだけ成り立つ」と書き直した。

直し方は 2 通りあり、どちらにするかは設計の判断である(設計の決定 7 は「ホストが最初に適用する形にならない」ことを目的にしている)。

直し方 変わるもの
手順書と docstring の主張を実装に合わせる 文書だけ。SKILL.md 側は #870 の書き換えで同時に直す(#870 が cross-refactoring/SKILL.md を drive の呼び出しへ縮める)
輪番の入力の並びか式を変え、全ホストでホストが最初に適用しないようにする 共通層 plugins/ndf/scripts/lib/assignment.py の impl_assign の振る舞いとテスト。#870 とは独立

決めること

上の 2 通りのどちらを採るか。

関連

直さないと何が起きるか

ホストが agy か kiro の利用者は、手順書を読んで「ホストは最初に適用しない」と期待するが、ラウンド 1 の適用はホスト自身が行う。

由来

PR #803(issue #664 の確定仕様)

閉じた理由(2026-09-26)

ラウンドの輪番(impl_assign)は無く、cross-refactoring の実装担当は --implementer → ホスト → 参加者の先頭で 1 者に決まる(cross-refactoring/SKILL.md の「担当の決め方」)。grep -rn impl_assign plugins/ndf/scripts/lib plugins/ndf/skills/cross-refactoring の当たりは tests/test_assignment.py:121 の assert not hasattr(assignment, "impl_assign") だけで、「ホストが最初に適用しない」の記述も無い。手順書と実装の食い違いは成り立たない。

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: ndf-skillNDF の Skill 本体documentationImprovements or additions to documentationneeds-decision方針の判断を待っているpriority: low文書のみ・低頻度など、余力があれば対応する

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions