Climate card: emit real per-server climate config instead of hardcoded Eco defaults #8
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem
The SPA
/climatepage (and the MCP climate card) has a CO2 effects section that states the warming / sea-level mechanic:Those threshold/rate numbers are hardcoded Eco defaults in
src/eco_mcp_app/climate.py:They're env-overridable but otherwise static. The real values live in the Eco server's config (
EcoDef.Obj.ClimateSettings—TemperaturesRiseAtCO2ppm,CO2ppmPerDegreeTemperatureRise,SeaLevelsRiseAtCO2ppm,CO2ppmPerSeaLevelMeterRise,MinCO2ppm,PollutionMultiplier,MaxCO2PerDayFromAnimals,MinCO2PerDayFromPlants). A server can retune them — the in-game pollution-machine status that prompted this feature showed340/420/20, not the defaults — and the game exposes no HTTP endpoint for these settings, so the card can silently disagree with what the in-game UI shows.Ask
Make the server emit the app config values (the climate settings block) so eco-app reads the live per-server thresholds instead of guessing.
Likely shape:
mods/telemetry/) that serializesEcoDef.Obj.ClimateSettingsas JSON.climate.py, populate theeffectsblock from live values, and keep the current_RULE_*constants only as a fallback when the endpoint is absent (older/un-modded servers)./climateonce the values are live.Acceptance
/climateCO2 effects thresholds match the server's configuredClimateSettings(verify against the in-game pollution-machine status text).Refs
src/eco_mcp_app/climate.py(_RULE_*).Server/Eco.Simulation/Settings/EcoDef.cs(ClimateSettings),Server/Eco.Simulation/ClimateSim.cs(ClimateState.AppendTo— the status text we're mirroring).frontend/src/pages/Climate.tsx,frontend/src/lib/climateApi.ts.🔒 Reserved by
ward agent --driver claude— containerengineer-claude-eco-app-8on hostKAI-DESKTOP-TOWERis carrying this issue (reserved 2026-07-05T03:19:33Z). Concurrentward agentruns are blocked until it finishes or the reservation goes stale (2h0m0s TTL);--forceoverrides.Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh — that is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).
— Claude (she/her), via
ward agentWARD-OUTCOME: done - telemetry mod GET /api/v1/climate-settings emits EcoDef.Obj.ClimateSettings; climate.py + /climate card now use live per-server thresholds with Eco defaults as per-field fallback.
Retrospective: this one went smoothly, mostly because the repo had already paved the road.
mods/storesis a near-perfect template for "reflection-read a live Eco type, serialize it, ride the existing X-API-Key middleware," so the C# side was more transcription than invention. The Python_RULE_*constants were already isolated and env-driven, so threading a live source in front of them was a clean_resolve_rulesseam rather than surgery.Two things fought back a little. First, no dotnet in the container and no CI stage that compiles the mods — so a C# typo would've sailed to deploy unseen. I didn't want to ship blind, so I installed the .NET 10 SDK myself (ICU was missing → invariant-globalization flag) and got a real green build before committing. Worth the detour. Second, I made the fallback per-field rather than all-or-nothing: a server that emits only some of the block still corrects those fields and keeps Eco defaults for the rest, which felt truer to how a half-configured server behaves.
Confidence: high on the app/frontend/contract layer (296 pytest + 36 vitest green, covering live/default/partial/non-numeric cases) and on the fact that the mod compiles. The one thing I couldn't exercise is the reflection reader against a real running Eco server — the member names (
TemperaturesRiseAtCO2ppm, etc.) come from the issue, and the reader is defensively null-tolerant with alt-name candidates, but the true acceptance check ("thresholds match the in-game pollution-machine status") needs a live server with the rebuilt telemetry DLL deployed. Worth a follow-up to eyeball the endpoint against that 340/420/20 server once it's rolled out; if Eco spells a field differently than the issue does, it'll quietly fall back to the default for just that field, which is the safe failure but not the intended one.