機能仕様書: apply_patch不要を目指すC#編集ワークフロー強化

[akiojin]

Spec

背景

unity-cli を C# 編集の主経路にして、apply_patch をフォールバックに落としたいです。実際に Unity プロジェクトを編集してみると、読み取りはかなり良い一方で、書き込みはまだ apply_patch を完全には置き換えられていません。

関連:

• 機能仕様書: C# LSP統合機能 #95 C# LSP統合機能
• feat(lsp): unity-mcp-serverから移行未完了のC#編集ツールをLSP経由で公開する #40 feat(lsp): unity-mcp-serverから移行未完了のC#編集ツールをLSP経由で公開する

課題

1. LSP 書き込みがデフォルトで使えない

• insert_before_symbol などが UNITY_CLI_LSP_MODE=auto or required を要求する
• 書き込み系だけ追加の前提が必要で UX が不連続

2. 書き込み結果が null になることがある

• replace_symbol_body / insert_before_symbol 実行後に null が返るケースがある
• 成功・no-op・失敗の判別がしづらい

3. symbol ベース挿入が不安定

• insert_before_symbol / insert_after_symbol が、対象シンボルが見えていても実ファイルに反映されないケースがある
• 成功判定と実際の変更がずれると厳しい

4. get_symbols が編集判断に十分でないことがある

• ファイルによっては、メソッドが十分に列挙されず field/class 中心になるケースがある
• namePath をそのまま write tool に渡せる一貫性が必要

5. 任意の C# ファイル新規作成が足りない

• create_class は便利だが、interface / enum / test file / 複数型を含むファイル / editor utility の作成には不足

6. 全文置換の validated write が欲しい

• validate_text_edits と別手段の apply を組み合わせる必要があり、ワークフローが分かれる

7. 複数ファイルを一括で atomic に編集したい

• interface + implementation + tests を同時に変えることが多い
• 1 ファイルずつだと途中失敗時に整合が崩れる

8. 編集後の再インデックス / 再コンパイル待機を一体化したい

• write -> refresh -> compile state poll -> symbols re-check を毎回やる必要がある

9. Project Settings / SettingsManagement を触る API が欲しい

• Code Coverage 設定のようなユースケースで editor utility を別途書く必要がある
• SettingsManagement ベースの project/user settings を直接触れれば、C# utility を増やさずに済む

欲しいコマンド案

• write_csharp_file(relative, newText, validate=true, apply=true)
• create_csharp_file(relative, text, validate=true, apply=true)
• apply_csharp_edits(files, validate=true, apply=true)
• write 系既存 tool の stronger contract
• get_project_setting / set_project_setting
• get_package_setting / set_package_setting

受け入れ基準

• UNITY_CLI_LSP_MODE を明示しなくても書き込み系が動作する
• 書き込み系コマンドが null を返さない
• symbol 挿入/置換で、実際に変更が入ったかを確実に判定できる
• interface / enum / test / utility を含む任意 C# ファイルを apply_patch なしで新規作成できる
• 3 ファイル以上の関連修正を atomic に適用できる
• 書き込み後に compile diagnostics まで受け取れる
• package/project settings の変更のために追加の editor utility を書かずに済む

Plan

1. issue 機能仕様書: apply_patch不要を目指すC#編集ワークフロー強化 #107 を gwt-spec 化し、Spec/Plan/Tasks/TDD を単一情報源として維持する
2. write 系の default LSP 化、共通レスポンス contract、namePath 正規化を先に実装する
3. write_csharp_file / create_csharp_file / apply_csharp_edits と post-write pipeline を実装する
4. get_project_setting / set_project_setting / get_package_setting / set_package_setting を追加する
5. Rust / LSP / Unity bridge のテストを追加し、品質ゲートを通す

Tasks

• issue 機能仕様書: apply_patch不要を目指すC#編集ワークフロー強化 #107 に gwt-spec ラベルを付け、進捗コメント運用を開始する
• write 系の default LSP 化を実装する
• write 系レスポンスを success/applied/changedFiles/changedSymbols/diagnostics/diffPreview/reason/backend に統一する
• get_symbols と write tool の namePath 整合を修正する
• write_csharp_file を追加する
• create_csharp_file を追加する
• apply_csharp_edits を追加する
• post-write の refresh / compile wait / index update を共通化する
• get_project_setting / set_project_setting を追加する
• get_package_setting / set_package_setting を追加する
• Rust / LSP / Unity bridge の回帰テストを追加する
• cargo fmt --all -- --check
• cargo clippy --all-targets -- -D warnings
• cargo test --all-targets
• dotnet test lsp/Server.Tests.csproj

TDD

• RED: まず write contract、namePath、新 API、settings API の失敗テストを追加する
• GREEN: 既存 LSP / Unity bridge の基盤を再利用して最小実装で通す
• REFACTOR: multi-file apply helper、post-write pipeline、settings handler を整理する
• 受け入れ基準に対応する統合テストを最後に揃える

[akiojin]

Progress

• Issue 機能仕様書: apply_patch不要を目指すC#編集ワークフロー強化 #107 を gwt-spec 形式に更新し、実装計画を Spec/Plan/Tasks/TDD に反映中
• write contract、namePath、new C# write APIs、settings APIs を順に実装する

Done

• 既存実装の調査を完了し、差分方針を確定
• ローカル作業ノートを Issue 機能仕様書: apply_patch不要を目指すC#編集ワークフロー強化 #107 向けに切り替え

Next

• src/local_tools.rs / src/lsp.rs / lsp/Program.cs で write 系 contract と default LSP 動作を実装

[akiojin]

Progress

• write 系の default LSP 化、共通レスポンス contract、namePath 整合を実装
• write_csharp_file / create_csharp_file / apply_csharp_edits と post-write pipeline を追加
• get_project_setting / set_project_setting / get_package_setting / set_package_setting を追加

Done

• issue 機能仕様書: apply_patch不要を目指すC#編集ワークフロー強化 #107 を gwt-spec 化し、Spec/Plan/Tasks/TDD を issue 本文に反映
• Rust 側の schema/dispatch/LSP transport を更新し、cargo clippy --all-targets -- -D warnings と cargo test --all-targets を通過
• Unity bridge に singular settings API を追加

Next

• Unity 環境で dotnet test lsp/Server.Tests.csproj と Unity 側コンパイル確認を行う
• package settings API は repo に SettingsManagement 依存が無いため、現状は project/user JSON ストアで動作させている。必要なら依存導入版へ切り替える

[akiojin]

Progress

• dotnet 9.0 SDK をローカル導入して LSP / Unity generated csproj の検証を追加実施
• Unity batchmode で listener 衝突を避ける修正と、UnityCliBridge.Tests.asmdef / manifest.json の test discovery 修正を実施

Done

• dotnet test lsp/Server.Tests.csproj は 3 tests pass
• dotnet build UnityCliBridge/UnityCliBridge.Editor.csproj と dotnet build UnityCliBridge/UnityCliBridge.Tests.csproj は success
• Unity batchmode の port 6400 競合と AssetEditingGuard assertion は解消

Next

• Unity の -runTests -testPlatform editmode は正常終了するが test-results/editmode-*.xml が生成されない。test runner 側の別 issue として切り分ける
• get_package_setting / set_package_setting は現状 JSON ストア実装。必要なら SettingsManagement 依存導入版へ発展させる

[akiojin]

Progress

• Rust / LSP / Unity generated csproj に加えて、この project 自身の Unity EditMode tests を batch 実行で確認
• integration tests は batch/test mode で listener を起動しない前提に合わせて専用ポート + skip へ修正

Done

• cargo clippy --all-targets -- -D warnings pass
• cargo test --all-targets pass (202 tests)
• dotnet test lsp/Server.Tests.csproj pass (3 tests)
• dotnet build UnityCliBridge/UnityCliBridge.Editor.csproj / UnityCliBridge.Tests.csproj success
• Unity EditMode tests: 145 total / 139 passed / 0 failed / 6 skipped

Next

• 公式 -runTests -testResults ... が指定先 XML を出さない挙動は別 issue 候補
• get_package_setting / set_package_setting は現状 JSON ストア実装。必要なら SettingsManagement 依存導入版へ拡張する

[akiojin]

Progress

• 実装を commit/push し、PR feat: strengthen C# edit workflow #108 を作成
• write workflow 強化、settings API、batch/test 安定化まで反映済み

Done

• PR feat: strengthen C# edit workflow #108: feat: strengthen C# edit workflow #108
• commit: c010483 (feat: strengthen C# edit workflow)
• 検証: Rust 202 tests pass, dotnet test 3 tests pass, Unity EditMode 145 total / 139 passed / 0 failed / 6 skipped

Next

• PR feat: strengthen C# edit workflow #108 の CI 結果を確認し、必要なら follow-up を入れる
• get_package_setting / set_package_setting を本物の SettingsManagement ベースへ上げるかは別判断

[akiojin]

Progress

• smoke E2E と full all-tools E2E をこの project の Unity Editor (127.0.0.1:6401) で実施
• E2E の前提ずれだった script payload / retry / new tool coverage / package setting fallback を修正

Done

• smoke E2E: 3/3 pass
• full all-tools E2E (--skip-lsp-perf --skip-quit): 119 invocation pass / 0 fail
• known skipped tools: rename_symbol, remove_symbol
• commit ff9acb2 pushed to PR feat: strengthen C# edit workflow #108

Next

• 必要なら rename_symbol / remove_symbol の live E2E も local LSP server 前提で別途追加する
• .cache/dotnet/sdk はローカル検証用に残してあるので、不要なら削除する

[akiojin]

Progress

• 機能仕様書: apply_patch不要を目指すC#編集ワークフロー強化 #107 の source of truth である issue 本文の Tasks を実装・検証結果に合わせて更新
• .cache/ を .gitignore に追加し、ローカル検証キャッシュが作業ツリーに残らないように整理

Done

• commit 67c6d59 (chore: ignore local cache directory) pushed
• issue 機能仕様書: apply_patch不要を目指すC#編集ワークフロー強化 #107 の Tasks は全項目チェック済み
• working tree is clean (local cache is ignored)

Next

• PR feat: strengthen C# edit workflow #108 の CI 監視とレビュー対応のみ

[akiojin]

gwt-spec ドメイン再編により #153 に統合