昨天有提到目前多數的功能似乎已經被實作出來，不過程式跑不起來。今天就針對這個部份來了解，看跑不起來的原因是Issue不夠清楚導致做出來的功能不完全，還是少了整合的部份，亦或是有其它的問題。接下來就會從已生成的專案中了解，先從核心專案來看

dotnet\GameConsole.Core.Abstractions\ICapabilityProvider.cs
dotnet\GameConsole.Core.Abstractions\IService.cs
dotnet\GameConsole.Core.Abstractions\IServiceMetadata.cs
dotnet\GameConsole.Core.Abstractions\ServiceAttribute.cs

之前在開立Issue時的確是以Service為主要架構方式進行製作，故在Core專案裡放入Service interface看起來很合理，且由於多為interface，也不會有什麼問題。Agent也有產生相對應的Test project，沒有細看的情況下，test也是沒有出現什麼問題。

dotnet\GameConsole.Core.Registry\IServiceRegistry.cs
dotnet\GameConsole.Core.Registry\ServiceComposition.cs
dotnet\GameConsole.Core.Registry\ServiceProvider.cs

由於是用Service的架構，那就會需要有Service Registry進行不同服務的註冊和存取，這裡的Registry主要就是負責這樣的功能。且會引用Pure.DI進行Dependency Injection，自然而然就會有Composition，且為了要模擬在Unity中的vContainer所提供的多層級的DI，也特地讓Agent仿製類似的用法將Parent-Child闗聯性置入。

  /// <summary>
  /// Sets the parent container for hierarchical service resolution.
  /// </summary>
  /// <param name="parent">The parent service provider.</param>
  public void SetParent(IServiceProvider parent)
  {
      _parent = parent;
  }

看到相對應的測試專案也有產生

dotnet\GameConsole.Core.Registry.Tests\CircularDependencyTests.cs
dotnet\GameConsole.Core.Registry.Tests\ServiceLifecycleIntegrationTests.cs

不過這些測試是完全跑不起來的，也就是說Agent在處理Registry的測試專案時就已出錯，沒能夠正確的完成。雖然Test不是必要完成的任務，但產出後不能執行，不如一開始就不要生成這些測試。然而沒有這些基本的測試，就要等到後續整合時才能確定是不是正確的，會更花時間。

但這就衍生出一個很實際的問題，在Issue產生時，有可能一開始沒有明確的定義測試要怎麼寫怎麼測，而現在測試專有問題。按照昨天所提及的概念是再生成另一個Issue，專門用來解決測試專案的問題。但目前這段還沒有進入到生成流程裡，不能如一開始這些功能開立一般直接走同樣的流程。最快的解決方法就是請local agent直接生成issue後，再讓GitHub coding agent接手後續。

dotnet\GameConsole.Engine.Core\IFrameRateManager.cs
dotnet\GameConsole.Engine.Core\IPhysicsService.cs

這個Engine.Core專案其實很奇怪，我記得當時和Agent討論時我是提及要作console tui的遊戲。但為什麼會出現IFramerateManager

/// <summary>
/// VSync modes for frame rate synchronization.
/// </summary>
public enum VSyncMode
{
    /// <summary>
    /// VSync disabled - unlimited frame rate.
    /// </summary>
    Disabled,
    
    /// <summary>
    /// VSync enabled - synchronize to display refresh rate.
    /// </summary>
    Enabled,
    
    /// <summary>
    /// Adaptive VSync - enable VSync when frame rate is above refresh rate.
    /// </summary>
    Adaptive,
    
    /// <summary>
    /// Half refresh rate VSync.
    /// </summary>
    Half
}

光是看到這enum就很確定這中間一定有什麼誤會，這也是權全交給Agent的一個問題。在它和你討論時，並不會出現這麼細項的資訊，而在Issue轉換成PR時，也可能還不會到這細節。直到GitHub coding agent開始進行型別生成時，這樣的細節才會出現。

而現階段是只要PR完成沒有compile time錯誤時，就會自動被approve後auto merge回到main。而這個型別並沒有任何語法或是語意上的問題，但從console app來看，這是很奇怪的。這可能是因為Agent的AI model訓練時比較偏向非console tui遊戲，因此在生成code時不自覺得就被影響到。這也是目前Agenth生成code時很容易出現的慣性。

比較早一些的AI model，像是gpt 4.1或是SWE-1(windsurf自行推的)，它們都有慣性，而且有些是很難改的慣性。就算是給它們看了文件、看了範例程式碼，還是無法改變它們產出的程式碼。還好，隨著Claude Sonnet 4和GPT-5的出現，大幅度的減少生成時的執著。

從Core.Registry.Test和Engine.Core二個專案來看，要開始規劃之後有哪些要調整的部份。今天也就只能先在這裡打住了。