revert old sim groundwork

AGENTS.md

@@ -4,11 +4,9 @@
 This repository should be organized as a Godot 4 .NET project from the root:
 
 - `project.godot` project entrypoint
-- `SideScrollerGame.csproj` and optional solution file
 - `scenes/` playable scenes such as `scenes/player/Player.tscn`
 - `scripts/` C# gameplay code paired with scenes
 - `assets/` sprites, audio, fonts, and tile sets
-- `tests/SideScrollerGame.Tests/` .NET test project for engine-light logic
 - `addons/` third-party Godot plugins when needed
 - `build/` local export output; do not commit generated files unless release workflow requires it
 
@@ -19,14 +17,12 @@ Run commands from the repository root. On Windows PowerShell, use the repo-local
 
 - `.\godot --editor --path .` opens the project in the editor
 - `.\godot --headless --path . --build-solutions` builds generated C# project files through Godot
-- `dotnet build` compiles the game assemblies and catches regular C# build errors
-- `dotnet test tests/SideScrollerGame.Tests` runs automated unit tests
-- `.\godot --headless --path . --export-release "Windows Desktop" ./build/SideScrollerGame.exe` exports a desktop build when presets are configured
+- `.\godot --headless --path . --export-release "Windows Desktop" ./build/zfxaction26_1.exe` exports a desktop build when presets are configured
 
 Document any custom wrapper scripts in `README.md` if the team adds them later.
 
 ## Coding Style & Naming Conventions
-Use 4 spaces for indentation, nullable reference types, and one primary public type per file. Keep Godot node scripts thin and move reusable gameplay rules into plain C# classes that do not depend on scene state.
+For C#, use 4 spaces for indentation, nullable reference types, and one primary public type per file. Keep Godot node scripts thin and move reusable gameplay rules into plain C# classes that do not depend on scene state.
 
 - `PascalCase` for classes, methods, properties, scene files, and C# scripts: `PlayerController`, `PlayerController.cs`
 - `m_PascalCase` for private fields
@@ -45,19 +41,13 @@ Keep a strict element order inside of types:
 - Events
 - Fields
 
-## Testing Guidelines
-Use a .NET test project under `tests/` and mirror gameplay areas, for example `tests/SideScrollerGame.Tests/Player/PlayerControllerTests.cs`. Prefer xUnit-style or NUnit-style tests for movement math, combat rules, save/load logic, and other engine-light systems.
-
-Add regression tests for every gameplay bug fix when practical. If scene-level automation is added later, keep it separate from fast unit tests.
-
 ## Working rules
 
-- This is a Windows environment, WSL is not installed (i.e. sed is not available). You're running under PowerShell 7.6.0. Due to platform restrictions, file deletions are not possible. Replacing the entire file content via a context diff is a viable alternative. 
-- PowerShell doesn't support bash-style heredocs. If complex scripts need to be executed, consider using python. Run Python code using python -c with inline commands instead of python - <<'PY'.
+- Follow operating system specific rules, either AGENTS.windows.md or AGENTS.linux.md
 - Before beginning with the edit phase, always present a plan first. Only begin editing after the user approves the plan.
 - Don't make assumptions in the plan. If necessary, ask all clarifying questions before presenting the final plan.
 - After every iteration, evaluate if the test coverage would fall below 100%, and write tests if necessary.
-- After every iteration, before committing, run `jb cleanupcode --build=False $file1;$file2;...` for every file you touched.
+- After every iteration, before committing, run `jb cleanupcode --build=False $file1;$file2;...` for every C# file you touched.
 - After every iteration, if there's a relevant documentation for the current task, update it according to the change.
   - Update the wording of touched concerns instead of introducing incremental change reports
   - The documentation should always represent the current state in its entirety and not derail into a historical development log.
@@ -70,10 +60,10 @@ Add regression tests for every gameplay bug fix when practical. If scene-level a
 ## Output generation
 
 ### User
-- For the user, you talk like a caveman. Speak only short grunts. Communicate in english.
+- For the user, you talk like a caveman. Speak only short grunts, conveying as much information in as few words as possible. Communicate in english.
 - Give no explanations unless explicitly asked. 
-- No fillers like 'happy to help'. Do task first. Show result. Stop.
-- For tools: "Tool work." then output the result and words like "Problem.", "Plan?", "Done."
+- No fillers like 'happy to help' or 'grunt'. Do task first. Show result. Stop.
+- For tools: "Tool work." then output the result and words like "Question:", "Problem.", "Plan?", "Done."
 - When working against a plan, don't give updates on partial plan milestones, check all plan tasks quietly until completely done.
 
 ### Reasoning