# LocalDiplomacy Implementation Status

Last updated: 2026-04-30

## Working / Implemented

### Bannerlord Module

- Module folder exists at `module/LocalDiplomacy`.
- `SubModule.xml` is present and configured for singleplayer.
- Module builds to:
  - `module/LocalDiplomacy/bin/Win64_Shipping_Client/LocalDiplomacy.dll`
- Current dependencies:
  - `Native`
  - `SandBoxCore`
  - `Sandbox`
  - `StoryMode`
- `LocalDiplomacy.SubModule` loads in Bannerlord.
- Campaign behavior is registered on campaign game start.
- Dedicated game-side log exists:
  - `Documents/Mount and Blade II Bannerlord/Configs/ModLogs/LocalDiplomacy.log`
- Dialogue hook is registered for several conversation tokens:
  - `lord_pretalk`
  - `lord_talk`
  - `lord_talk_speak_diplomacy_2`
  - `hero_main_options`
  - `hero_talk`
  - `start`
- In-game dialogue option exists:
  - `[LocalDiplomacy] Ask what news they have.`
- Selecting the dialogue option sends a compact `ConversationRequest` to the local Python agent.
- Game client is hardcoded to call:
  - `http://127.0.0.1:8766`
- Game client logs outgoing payloads and failed HTTP responses.
- Agent responses are displayed in-game with `InformationManager.DisplayMessage`.
- Returned game actions are passed through local validation before execution.
- Action executor currently displays accepted actions as messages.

### Python Agent

- FastAPI agent exists at `src/LocalDiplomacy.Agent`.
- Agent runs with `uv`.
- Main app module:
  - `localdiplomacy_agent.app:app`
- Main endpoints implemented:
  - `GET /health`
  - `GET /debug/status`
  - `POST /conversation/respond`
  - `POST /world/tick`
  - `POST /actions/result`
- Web dashboard exists:
  - `http://127.0.0.1:8766/ui`
- Dashboard shows:
  - agent status
  - KoboldCpp reachability
  - memory status
  - last latency
  - live logs
  - KoboldCpp API address
  - model id
  - timeout
- Dashboard can update KoboldCpp API settings.
- Dashboard can ping KoboldCpp.
- KoboldCpp API can point at another machine, for example:
  - `http://192.168.1.17:5001`
- Agent logs game requests, agent replies, queued actions, warnings, and errors.
- Agent config persists to `config.yaml`.
- Agent supports `/no_think` prompt prefixing for Qwen3-style thinking models.
- Agent uses focused tool selection for action-looking requests.
- Agent uses narrowed action schemas for small models.
- Agent can force `propose_game_action` tool calls for explicit action requests.
- Python contract accepts C#-style nullable `traits`.
- Memory layer scaffold exists and currently defaults to disabled.
- SQLite event ledger exists.

### KoboldCpp / Model Testing

- KoboldCpp OpenAI-compatible `/v1/chat/completions` flow is implemented.
- Tool calling uses OpenAI-style `tools` and `tool_choice`.
- Model smoke-test script exists:
  - `scripts/test_kobold_model.py`
- Smoke-test script accepts:
  - model path
  - context size
  - KoboldCpp path
  - port
  - keep-running flag
  - stop-existing flag
  - extra KoboldCpp args
- Smoke-test script runs:
  - normal dialogue test
  - auto tool-call test
  - forced tool-call test
  - LocalDiplomacy action-planner tool-call test
- `Qwen3-4B-abliterated-q4_k_m.gguf` was tested at `40960` context and passed smoke tests with `/no_think`.

### Tests / Build

- Python test suite passes.
- Current Python test count:
  - 11 tests
- C# module builds successfully with local .NET SDK and Bannerlord references.
- Build command:
  ```powershell
  $env:PATH="$env:USERPROFILE\.dotnet;$env:PATH"
  $env:BANNERLORD_REFERENCES="D:\SteamLibrary\steamapps\common\Mount & Blade II Bannerlord\bin\Win64_Shipping_Client"
  dotnet build src\LocalDiplomacy\LocalDiplomacy.csproj
  ```

## Partially Implemented / Scaffolded

### Bannerlord Gameplay Integration

- Dialogue integration is currently a single debug-style option.
- Player cannot yet type custom dialogue text inside Bannerlord.
- NPC answer is currently displayed as an information message, not as a full custom conversation UI.
- No Gauntlet UI has been built inside the game.
- No confirmation UI exists yet for dangerous actions.
- Local validation exists, but most action-specific validation is still basic.
- Action execution is mostly placeholder behavior.
- World tick endpoint exists, but the game does not yet send rich world diffs.
- Nearby parties, settlements, kingdom state, and recent events are still minimal in the in-game request.

### Agent

- Tool registry contains broad AIInfluence-style feature coverage.
- Many tools are declared but backed by placeholder/read-only behavior until the Bannerlord connector supplies richer live data.
- Memory storage is scaffolded but disabled by default.
- Mem0 + Qdrant is planned but not wired as the default runtime path yet.
- No separate desktop UI exists; the current UI is browser-based FastAPI HTML.

## Known Issues / Watch Items

- Small models can narrate tool intentions unless `/no_think`, narrowed schemas, and forced tool calls are used.
- Full tool catalog is too large for reliable 4B model tool choice.
- The Python dashboard updates KoboldCpp settings at runtime, but active in-flight calls use the currently loaded config object.
- Bannerlord must be closed before rebuilding if the DLL is locked.
- The first working in-game path depends on the player selecting the debug dialogue option.
- Returned action execution is intentionally conservative and mostly non-mutating.

## Next Recommended Work

1. Replace the debug prompt with a small in-game text input or selectable prompt menu.
2. Show NPC responses in a proper dialogue/inquiry window instead of only notification messages.
3. Expand `BuildDebugConversationRequest` with real nearby parties, settlement, war, clan, and kingdom context.
4. Add confirmation UI for diplomacy, hostile, and high-impact actions.
5. Implement a small set of real Bannerlord mutations:
   - follow player
   - patrol settlement
   - propose peace
   - declare war proposal validation only
6. Wire world tick diffs from Bannerlord to the agent.
7. Enable Mem0 + Qdrant memory once the dialogue loop is stable.