添加 claude code game studios 到项目
This commit is contained in:
panw
@@ -0,0 +1,81 @@
|
||||
# Agent Test Spec: godot-csharp-specialist
|
||||
|
||||
## Agent Summary
|
||||
Domain: C# patterns in Godot 4, .NET idioms applied to Godot, [Export] attribute usage, signal delegates, and async/await patterns.
|
||||
Does NOT own: GDScript code (gdscript-specialist), GDExtension C/C++ bindings (gdextension-specialist).
|
||||
Model tier: Sonnet (default).
|
||||
No gate IDs assigned.
|
||||
|
||||
---
|
||||
|
||||
## Static Assertions (Structural)
|
||||
|
||||
- [ ] `description:` field is present and domain-specific (references C# in Godot 4 / .NET patterns / signal delegates)
|
||||
- [ ] `allowed-tools:` list includes Read, Write, Edit, Bash, Glob, Grep
|
||||
- [ ] Model tier is Sonnet (default for specialists)
|
||||
- [ ] Agent definition does not claim authority over GDScript or GDExtension code
|
||||
|
||||
---
|
||||
|
||||
## Test Cases
|
||||
|
||||
### Case 1: In-domain request — appropriate output
|
||||
**Input:** "Create an export property for enemy health with validation that clamps it between 1 and 1000."
|
||||
**Expected behavior:**
|
||||
- Produces a C# property with `[Export]` attribute
|
||||
- Uses a backing field with a property getter/setter that clamps the value in the setter
|
||||
- Does NOT use a raw `[Export]` public field without validation
|
||||
- Follows Godot 4 C# naming conventions (PascalCase for properties, fields private with underscore prefix)
|
||||
- Includes XML doc comment on the property per coding standards
|
||||
|
||||
### Case 2: Out-of-domain request — redirects correctly
|
||||
**Input:** "Rewrite this enemy health system in GDScript."
|
||||
**Expected behavior:**
|
||||
- Does NOT produce GDScript code
|
||||
- Explicitly states that GDScript authoring belongs to `godot-gdscript-specialist`
|
||||
- Redirects the request to `godot-gdscript-specialist`
|
||||
- May note that the C# interface can be described so the gdscript-specialist knows the expected API shape
|
||||
|
||||
### Case 3: Async signal awaiting
|
||||
**Input:** "Wait for an animation to finish before transitioning game state using C# async."
|
||||
**Expected behavior:**
|
||||
- Produces a proper `async Task` pattern using `ToSignal()` to await a Godot signal
|
||||
- Uses `await ToSignal(animationPlayer, AnimationPlayer.SignalName.AnimationFinished)`
|
||||
- Does NOT use `Thread.Sleep()` or `Task.Delay()` as a polling substitute
|
||||
- Notes that the calling method must be `async` and that fire-and-forget `async void` is only acceptable for event handlers
|
||||
- Handles cancellation or timeout if the animation could fail to fire
|
||||
|
||||
### Case 4: Threading model conflict
|
||||
**Input:** "This C# code accesses a Godot Node from a background Task thread to update its position."
|
||||
**Expected behavior:**
|
||||
- Flags this as a race condition risk: Godot nodes are not thread-safe and must only be accessed from the main thread
|
||||
- Does NOT approve or implement the multi-threaded node access pattern
|
||||
- Provides the correct pattern: use `CallDeferred()`, `Callable.From().CallDeferred()`, or marshal back to the main thread via a thread-safe queue
|
||||
- Explains the distinction between Godot's main thread requirement and .NET's thread-agnostic types
|
||||
|
||||
### Case 5: Context pass — Godot 4.6 API correctness
|
||||
**Input:** Engine version context: Godot 4.6. Request: "Connect a signal using the new typed signal delegate pattern."
|
||||
**Expected behavior:**
|
||||
- Produces C# signal connection using the typed delegate pattern introduced in Godot 4 C# (`+=` operator on typed signal)
|
||||
- Checks the 4.6 context to confirm no breaking changes to the signal delegate API in 4.4, 4.5, or 4.6
|
||||
- Does NOT use the old string-based `Connect("signal_name", callable)` pattern (deprecated in Godot 4 C#)
|
||||
- Produces code compatible with the project's pinned 4.6 version as documented in VERSION.md
|
||||
|
||||
---
|
||||
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] Stays within declared domain (C# in Godot 4 — patterns, exports, signals, async)
|
||||
- [ ] Redirects GDScript requests to godot-gdscript-specialist
|
||||
- [ ] Redirects GDExtension requests to godot-gdextension-specialist
|
||||
- [ ] Returns C# code following Godot 4 conventions (not Unity MonoBehaviour patterns)
|
||||
- [ ] Flags multi-threaded Godot node access as unsafe and provides the correct pattern
|
||||
- [ ] Uses typed signal delegates — not deprecated string-based Connect() calls
|
||||
- [ ] Checks engine version reference for API changes before producing code
|
||||
|
||||
---
|
||||
|
||||
## Coverage Notes
|
||||
- Export property with validation (Case 1) should have a unit test verifying the clamp behavior
|
||||
- Threading conflict (Case 4) is safety-critical: the agent must identify and fix this without prompting
|
||||
- Async signal (Case 3) verifies the agent applies .NET idioms correctly within Godot's single-thread constraint
|
||||
@@ -0,0 +1,86 @@
|
||||
# Agent Test Spec: godot-gdextension-specialist
|
||||
|
||||
## Agent Summary
|
||||
Domain: GDExtension API, godot-cpp C++ bindings, godot-rust bindings, native library integration, and native performance optimization.
|
||||
Does NOT own: GDScript code (gdscript-specialist), shader code (godot-shader-specialist).
|
||||
Model tier: Sonnet (default).
|
||||
No gate IDs assigned.
|
||||
|
||||
---
|
||||
|
||||
## Static Assertions (Structural)
|
||||
|
||||
- [ ] `description:` field is present and domain-specific (references GDExtension / godot-cpp / native bindings)
|
||||
- [ ] `allowed-tools:` list includes Read, Write, Edit, Bash, Glob, Grep
|
||||
- [ ] Model tier is Sonnet (default for specialists)
|
||||
- [ ] Agent definition does not claim authority over GDScript or shader authoring
|
||||
|
||||
---
|
||||
|
||||
## Test Cases
|
||||
|
||||
### Case 1: In-domain request — appropriate output
|
||||
**Input:** "Expose a C++ rigid-body physics simulation library to GDScript via GDExtension."
|
||||
**Expected behavior:**
|
||||
- Produces a GDExtension binding pattern using godot-cpp:
|
||||
- Class inheriting from `godot::Object` or an appropriate Godot base class
|
||||
- `GDCLASS` macro registration
|
||||
- `_bind_methods()` implementation exposing the physics API to GDScript
|
||||
- `GDExtension` entry point (`gdextension_init`) setup
|
||||
- Notes the `.gdextension` manifest file format required
|
||||
- Does NOT produce the GDScript usage code (that belongs to gdscript-specialist)
|
||||
|
||||
### Case 2: Out-of-domain redirect
|
||||
**Input:** "Write the GDScript that calls the physics simulation from Case 1."
|
||||
**Expected behavior:**
|
||||
- Does NOT produce GDScript code
|
||||
- Explicitly states that GDScript authoring belongs to `godot-gdscript-specialist`
|
||||
- Redirects to `godot-gdscript-specialist`
|
||||
- May describe the API surface the GDScript should call (method names, parameter types) as a handoff spec
|
||||
|
||||
### Case 3: ABI compatibility risk — minor version update
|
||||
**Input:** "We're upgrading from Godot 4.5 to 4.6. Will our existing GDExtension still work?"
|
||||
**Expected behavior:**
|
||||
- Flags the ABI compatibility concern: GDExtension binaries may not be ABI-compatible across minor versions
|
||||
- Directs to check the 4.5→4.6 migration guide for GDExtension API changes
|
||||
- Recommends recompiling the extension against the 4.6 godot-cpp headers rather than assuming binary compatibility
|
||||
- Notes that the `.gdextension` manifest may need a `compatibility_minimum` version update
|
||||
- Provides the recompilation checklist
|
||||
|
||||
### Case 4: Memory management — RAII for Godot objects
|
||||
**Input:** "How should we manage the lifecycle of Godot objects created inside C++ GDExtension code?"
|
||||
**Expected behavior:**
|
||||
- Produces the RAII-based lifecycle pattern for Godot objects in GDExtension:
|
||||
- `Ref<T>` for reference-counted objects (auto-released when Ref goes out of scope)
|
||||
- `memnew()` / `memdelete()` for non-reference-counted objects
|
||||
- Warning: do NOT use `new`/`delete` for Godot objects — undefined behavior
|
||||
- Notes object ownership rules: who is responsible for freeing a node added to the scene tree
|
||||
- Provides a concrete example managing a `CollisionShape3D` created in C++
|
||||
|
||||
### Case 5: Context pass — Godot 4.6 GDExtension API check
|
||||
**Input:** Engine version context: Godot 4.6 (upgrading from 4.5). Request: "Check if any GDExtension APIs changed from 4.5 to 4.6."
|
||||
**Expected behavior:**
|
||||
- References the 4.5→4.6 migration guide from the VERSION.md verified sources list
|
||||
- Reports on any documented GDExtension API changes in the 4.6 release
|
||||
- If no breaking changes are documented for GDExtension in 4.6, states that explicitly with the caveat to verify against the official changelog
|
||||
- Flags the D3D12 default on Windows (4.6 change) as potentially relevant for GDExtension rendering code
|
||||
- Provides a checklist of what to verify after upgrading
|
||||
|
||||
---
|
||||
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] Stays within declared domain (GDExtension, godot-cpp, godot-rust, native bindings)
|
||||
- [ ] Redirects GDScript authoring to godot-gdscript-specialist
|
||||
- [ ] Redirects shader authoring to godot-shader-specialist
|
||||
- [ ] Returns structured output (binding patterns, RAII examples, ABI checklists)
|
||||
- [ ] Flags ABI compatibility risks on minor version upgrades — never assumes binary compatibility
|
||||
- [ ] Uses Godot-specific memory management (`memnew`/`memdelete`, `Ref<T>`) not raw C++ new/delete
|
||||
- [ ] Checks engine version reference for GDExtension API changes before confirming compatibility
|
||||
|
||||
---
|
||||
|
||||
## Coverage Notes
|
||||
- Binding pattern (Case 1) should include a smoke test verifying the extension loads and the method is callable from GDScript
|
||||
- ABI risk (Case 3) is a critical escalation path — the agent must not approve shipping an unverified extension binary
|
||||
- Memory management (Case 4) verifies the agent applies Godot-specific patterns, not generic C++ RAII
|
||||
@@ -0,0 +1,82 @@
|
||||
# Agent Test Spec: godot-gdscript-specialist
|
||||
|
||||
## Agent Summary
|
||||
Domain: GDScript static typing, design patterns in GDScript, signal architecture, coroutine/await patterns, and GDScript performance.
|
||||
Does NOT own: shader code (godot-shader-specialist), GDExtension bindings (godot-gdextension-specialist).
|
||||
Model tier: Sonnet (default).
|
||||
No gate IDs assigned.
|
||||
|
||||
---
|
||||
|
||||
## Static Assertions (Structural)
|
||||
|
||||
- [ ] `description:` field is present and domain-specific (references GDScript / static typing / signals / coroutines)
|
||||
- [ ] `allowed-tools:` list includes Read, Write, Edit, Bash, Glob, Grep
|
||||
- [ ] Model tier is Sonnet (default for specialists)
|
||||
- [ ] Agent definition does not claim authority over shader code or GDExtension
|
||||
|
||||
---
|
||||
|
||||
## Test Cases
|
||||
|
||||
### Case 1: In-domain request — appropriate output
|
||||
**Input:** "Review this GDScript file for type annotation coverage."
|
||||
**Expected behavior:**
|
||||
- Reads the provided GDScript file
|
||||
- Flags every variable, parameter, and return type that is missing a static type annotation
|
||||
- Produces a list of specific line-by-line findings: `var speed = 5.0` → `var speed: float = 5.0`
|
||||
- Notes the performance and tooling benefits of static typing in Godot 4
|
||||
- Does NOT rewrite the entire file unprompted — produces a findings list for the developer to apply
|
||||
|
||||
### Case 2: Out-of-domain request — redirects correctly
|
||||
**Input:** "Write a vertex shader to distort the mesh in world space."
|
||||
**Expected behavior:**
|
||||
- Does NOT produce shader code in GDScript or in Godot's shading language
|
||||
- Explicitly states that shader authoring belongs to `godot-shader-specialist`
|
||||
- Redirects the request to `godot-shader-specialist`
|
||||
- May note that the GDScript side (passing uniforms to a shader, setting shader parameters) is within its domain
|
||||
|
||||
### Case 3: Async loading with coroutines
|
||||
**Input:** "Load a scene asynchronously and wait for it to finish before spawning it."
|
||||
**Expected behavior:**
|
||||
- Produces an `await` + `ResourceLoader.load_threaded_request` pattern for Godot 4
|
||||
- Uses static typing throughout (`var scene: PackedScene`)
|
||||
- Handles the completion check with `ResourceLoader.load_threaded_get_status()`
|
||||
- Notes error handling for failed loads
|
||||
- Does NOT use deprecated Godot 3 `yield()` syntax
|
||||
|
||||
### Case 4: Performance issue — typed array recommendation
|
||||
**Input:** "The entity update loop is slow; it iterates an untyped Array of 1,000 nodes every frame."
|
||||
**Expected behavior:**
|
||||
- Identifies that an untyped `Array` foregoes compiler optimization in GDScript
|
||||
- Recommends converting to a typed array (`Array[Node]` or the specific type) to enable JIT hints
|
||||
- Notes that if this is still insufficient, escalates the hot path to C# migration recommendation
|
||||
- Produces the typed array refactor as the immediate fix
|
||||
- Does NOT recommend migrating the entire codebase to C# without profiling evidence
|
||||
|
||||
### Case 5: Context pass — Godot 4.6 with post-cutoff features
|
||||
**Input:** Engine version context provided: Godot 4.6. Request: "Create an abstract base class for all enemy types using @abstract."
|
||||
**Expected behavior:**
|
||||
- Identifies `@abstract` as a Godot 4.5+ feature (post-cutoff)
|
||||
- Notes this in the output: feature introduced in 4.5, verified against VERSION.md migration notes
|
||||
- Produces the GDScript class using `@abstract` with correct syntax as documented in migration notes
|
||||
- Marks the output as requiring verification against the official 4.5 release notes due to post-cutoff status
|
||||
- Uses static typing for all method signatures in the abstract class
|
||||
|
||||
---
|
||||
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] Stays within declared domain (GDScript — typing, patterns, signals, coroutines, performance)
|
||||
- [ ] Redirects shader requests to godot-shader-specialist
|
||||
- [ ] Redirects GDExtension requests to godot-gdextension-specialist
|
||||
- [ ] Returns structured GDScript output with full static typing
|
||||
- [ ] Uses Godot 4 API only — no deprecated Godot 3 patterns (yield, connect with strings, etc.)
|
||||
- [ ] Flags post-cutoff features (4.4, 4.5, 4.6) and marks them as requiring doc verification
|
||||
|
||||
---
|
||||
|
||||
## Coverage Notes
|
||||
- Type annotation review (Case 1) output is suitable as a code review checklist
|
||||
- Async loading (Case 3) should produce testable code verifiable with a unit test in `tests/unit/`
|
||||
- Post-cutoff @abstract (Case 5) confirms the agent flags version uncertainty rather than silently using unverified APIs
|
||||
@@ -0,0 +1,84 @@
|
||||
# Agent Test Spec: godot-shader-specialist
|
||||
|
||||
## Agent Summary
|
||||
Domain: Godot shading language (GLSL-derivative), visual shaders (VisualShader graph), material setup, particle shaders, and post-processing effects.
|
||||
Does NOT own: gameplay code, art style direction.
|
||||
Model tier: Sonnet (default).
|
||||
No gate IDs assigned.
|
||||
|
||||
---
|
||||
|
||||
## Static Assertions (Structural)
|
||||
|
||||
- [ ] `description:` field is present and domain-specific (references Godot shading language / materials / post-processing)
|
||||
- [ ] `allowed-tools:` list includes Read, Write, Edit, Glob, Grep
|
||||
- [ ] Model tier is Sonnet (default for specialists)
|
||||
- [ ] Agent definition references `docs/engine-reference/godot/VERSION.md` as the authoritative source for Godot shader API changes
|
||||
|
||||
---
|
||||
|
||||
## Test Cases
|
||||
|
||||
### Case 1: In-domain request — appropriate output
|
||||
**Input:** "Write a dissolve effect shader for enemy death in Godot."
|
||||
**Expected behavior:**
|
||||
- Produces valid Godot shading language code (not HLSL, not GLSL directly)
|
||||
- Uses `shader_type spatial;` or `canvas_item` as appropriate
|
||||
- Defines `uniform float dissolve_amount : hint_range(0.0, 1.0);`
|
||||
- Samples a noise texture to determine per-pixel dissolve threshold
|
||||
- Uses `discard;` for pixels below the threshold
|
||||
- Optionally adds an edge glow using emission near the dissolve boundary
|
||||
- Code is syntactically correct for Godot's shading language
|
||||
|
||||
### Case 2: HLSL redirect
|
||||
**Input:** "Write an HLSL compute shader for this dissolve effect."
|
||||
**Expected behavior:**
|
||||
- Does NOT produce HLSL code
|
||||
- Clearly states: "Godot does not use HLSL directly; it uses its own shading language (a GLSL derivative)"
|
||||
- Translates the HLSL intent to the equivalent Godot shader approach
|
||||
- Notes that RenderingDevice compute shaders are available in Godot 4 but are a low-level API and flags it appropriately if that was the intent
|
||||
|
||||
### Case 3: Post-cutoff API change — texture sampling (Godot 4.4)
|
||||
**Input:** "Use `texture()` with a sampler2D to sample the noise texture in the shader."
|
||||
**Expected behavior:**
|
||||
- Checks the version reference: Godot 4.4 changed texture sampler type declarations
|
||||
- Flags the potential API change: `sampler2D` syntax and `texture()` call behavior may differ from pre-4.4
|
||||
- Provides the correct syntax for the project's pinned version (4.6) as documented in migration notes
|
||||
- Does NOT use pre-4.4 texture sampling syntax without flagging the version risk
|
||||
|
||||
### Case 4: Fragment shader LOD strategy
|
||||
**Input:** "The fragment shader for the water surface has 8 texture samples and is causing GPU bottlenecks on mid-range hardware."
|
||||
**Expected behavior:**
|
||||
- Identifies the per-fragment texture sample count as the primary cost driver
|
||||
- Proposes an LOD strategy:
|
||||
- Reduce sample count at distance (distance-based shader variant or LOD level)
|
||||
- Pre-bake some texture combinations offline
|
||||
- Use lower-resolution noise textures for distant samples
|
||||
- Provides the shader code modification implementing the LOD approach
|
||||
- Does NOT change gameplay behavior of the water system
|
||||
|
||||
### Case 5: Context pass — Godot 4.6 glow rework
|
||||
**Input:** Engine version context: Godot 4.6. Request: "Add a bloom/glow post-processing effect to the scene."
|
||||
**Expected behavior:**
|
||||
- References the VERSION.md note: Godot 4.6 includes a glow rework
|
||||
- Produces glow configuration guidance using the 4.6 WorldEnvironment approach, not the pre-4.6 API
|
||||
- Explicitly notes which properties or parameters changed in the 4.6 glow rework
|
||||
- Flags any properties that the LLM's training data may have incorrect information about due to the post-cutoff timing
|
||||
|
||||
---
|
||||
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] Stays within declared domain (Godot shading language, materials, VFX shaders, post-processing)
|
||||
- [ ] Redirects gameplay code requests to gameplay-programmer
|
||||
- [ ] Produces valid Godot shading language — never HLSL or raw GLSL without a Godot wrapper
|
||||
- [ ] Checks engine version reference for post-cutoff shader API changes (4.4 texture types, 4.6 glow rework)
|
||||
- [ ] Returns structured output (shader code with uniforms documented, LOD strategies with performance rationale)
|
||||
- [ ] Flags any post-cutoff API usage as requiring verification
|
||||
|
||||
---
|
||||
|
||||
## Coverage Notes
|
||||
- Dissolve shader (Case 1) should be paired with a visual test screenshot in `production/qa/evidence/`
|
||||
- Texture API flag (Case 3) confirms the agent checks VERSION.md before using APIs that changed post-4.3
|
||||
- Glow rework (Case 5) is a Godot 4.6-specific test — verifies the agent applies the most recent migration notes
|
||||
@@ -0,0 +1,82 @@
|
||||
# Agent Test Spec: godot-specialist
|
||||
|
||||
## Agent Summary
|
||||
Domain: Godot-specific patterns, node/scene architecture, signals, resources, and GDScript vs C# vs GDExtension decisions.
|
||||
Does NOT own: actual code authoring in a specific language (delegates to language sub-specialists).
|
||||
Model tier: Sonnet (default).
|
||||
No gate IDs assigned.
|
||||
|
||||
---
|
||||
|
||||
## Static Assertions (Structural)
|
||||
|
||||
- [ ] `description:` field is present and domain-specific (references Godot architecture / node patterns / engine decisions)
|
||||
- [ ] `allowed-tools:` list includes Read, Write, Edit, Bash, Glob, Grep
|
||||
- [ ] Model tier is Sonnet (default for specialists)
|
||||
- [ ] Agent definition references `docs/engine-reference/godot/VERSION.md` as the authoritative API source
|
||||
|
||||
---
|
||||
|
||||
## Test Cases
|
||||
|
||||
### Case 1: In-domain request — appropriate output
|
||||
**Input:** "When should I use signals vs. direct method calls in Godot?"
|
||||
**Expected behavior:**
|
||||
- Produces a pattern decision guide with rationale:
|
||||
- Signals: decoupled communication, parent-to-child ignorance, event-driven UI updates, one-to-many notification
|
||||
- Direct calls: tightly-coupled systems where the caller needs a return value, or performance-critical hot paths
|
||||
- Provides concrete examples of each pattern in the project's context
|
||||
- Does NOT produce raw code for both patterns — refers to gdscript-specialist or csharp-specialist for implementation
|
||||
- Notes the "no upward signals" convention (child does not call parent methods directly — uses signals instead)
|
||||
|
||||
### Case 2: Wrong-engine redirect
|
||||
**Input:** "Write a MonoBehaviour that runs on Start() and subscribes to a UnityEvent."
|
||||
**Expected behavior:**
|
||||
- Does NOT produce Unity MonoBehaviour code
|
||||
- Clearly identifies that this is a Unity pattern, not a Godot pattern
|
||||
- Provides the Godot equivalent: a Node script using `_ready()` instead of `Start()`, and Godot signals instead of UnityEvent
|
||||
- Confirms the project is Godot-based and redirects the conceptual mapping
|
||||
|
||||
### Case 3: Post-cutoff API risk
|
||||
**Input:** "Use the new Godot 4.5 @abstract annotation to define an abstract base class."
|
||||
**Expected behavior:**
|
||||
- Identifies that `@abstract` is a post-cutoff feature (introduced in Godot 4.5, after LLM knowledge cutoff)
|
||||
- Flags the version risk: LLM knowledge of this annotation may be incomplete or incorrect
|
||||
- Directs the user to verify against `docs/engine-reference/godot/VERSION.md` and the official 4.5 migration guide
|
||||
- Provides best-effort guidance based on the migration notes in the version reference while clearly marking it as unverified
|
||||
|
||||
### Case 4: Language selection for a hot path
|
||||
**Input:** "The physics query loop runs every frame for 500 objects. Should we use GDScript or C# for this?"
|
||||
**Expected behavior:**
|
||||
- Provides a balanced analysis:
|
||||
- GDScript: simpler, team familiar, but slower for tight loops
|
||||
- C#: faster for CPU-intensive loops, requires .NET runtime, team needs C# knowledge
|
||||
- Does NOT make the final decision unilaterally
|
||||
- Defers the decision to `lead-programmer` with the analysis as input
|
||||
- Notes that GDExtension (C++) is a third option for extreme performance cases and recommends escalating if C# is insufficient
|
||||
|
||||
### Case 5: Context pass — engine version 4.6
|
||||
**Input:** Engine version context provided: Godot 4.6, Jolt as default physics. Request: "Set up a RigidBody3D for the player character."
|
||||
**Expected behavior:**
|
||||
- Reads the 4.6 context and applies the Jolt-default knowledge (from VERSION.md migration notes)
|
||||
- Recommends RigidBody3D configuration choices that are Jolt-compatible (e.g., notes any GodotPhysics-specific settings that behave differently under Jolt)
|
||||
- References the 4.6 migration note about Jolt becoming default rather than relying on LLM training data alone
|
||||
- Flags any RigidBody3D properties that changed behavior between GodotPhysics and Jolt
|
||||
|
||||
---
|
||||
|
||||
## Protocol Compliance
|
||||
|
||||
- [ ] Stays within declared domain (Godot architecture decisions, node/scene patterns, language selection)
|
||||
- [ ] Redirects language-specific implementation to godot-gdscript-specialist or godot-csharp-specialist
|
||||
- [ ] Returns structured findings (decision trees, pattern recommendations with rationale)
|
||||
- [ ] Treats `docs/engine-reference/godot/VERSION.md` as authoritative over LLM training data
|
||||
- [ ] Flags post-cutoff API usage (4.4, 4.5, 4.6) with verification requirements
|
||||
- [ ] Defers language-selection decisions to lead-programmer when trade-offs exist
|
||||
|
||||
---
|
||||
|
||||
## Coverage Notes
|
||||
- Signal vs. direct call guide (Case 1) should be written to `docs/architecture/` as a reusable pattern doc
|
||||
- Post-cutoff flag (Case 3) confirms the agent does not confidently use APIs it cannot verify
|
||||
- Engine version case (Case 5) verifies the agent applies migration notes from the version reference, not assumptions
|
||||
Reference in New Issue
Block a user