totalCulture: 0 from /info propagates into get_economy KPIs and get_milestones alongside 910 culture of visible progress #237

New issue

Closed

opened 2026-08-12 23:16:04 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-12 23:16:04 +00:00

Member

QA sweep, Eco via Sirens, day 40, 2026-08-12.

Observed

On Eco via Sirens, three tools report zero culture:

get_server_status → world.totalCulture: 0
get_economy → kpis.total_culture: 0
get_milestones → totalCulture: 0

while get_milestones simultaneously lists real progress in the same payload:

{"name":"Ascendent Civilization","current":910.32,"target":100000,"pct":0.91},
{"name":"Cultural Nexus","current":384.57,"target":20000},
{"name":"Sparkling Canvas","current":27.71,"target":50,"pct":55.42}

910.32 culture from 26 works by 18 artists, next to a headline of 0.

Not our bug, but ours to handle

The zero comes from upstream /info, not from us — GreenLeaf Prime returns totalCulture: 1291.86 through the same code path on the same fetch. So the field is unreliable per server rather than always broken.

Expected

When /info reports 0 but milestone progress is non-zero, prefer the milestone maximum (or reconcile and flag). Right now get_economy publishes total_culture: 0 as an economic KPI for a server with visible cultural output, and a reader has no way to know the field is untrustworthy.

Minor, same surface

world.animals: 0 on both servers tested, while get_region tracks live animal populations (Deer 248, Wolf 167, Bison 114). Same shape of problem — the /info field looks unpopulated and we pass it through unmarked.
GreenLeaf returns daysUntilMeteor: -17 with hasMeteor: false; a negative countdown for a meteor that does not exist should probably be null.

QA sweep, Eco via Sirens, day 40, 2026-08-12. ## Observed On Eco via Sirens, three tools report zero culture: - `get_server_status` → `world.totalCulture: 0` - `get_economy` → `kpis.total_culture: 0` - `get_milestones` → `totalCulture: 0` while `get_milestones` simultaneously lists real progress in the same payload: ```json {"name":"Ascendent Civilization","current":910.32,"target":100000,"pct":0.91}, {"name":"Cultural Nexus","current":384.57,"target":20000}, {"name":"Sparkling Canvas","current":27.71,"target":50,"pct":55.42} ``` 910.32 culture from 26 works by 18 artists, next to a headline of 0. ## Not our bug, but ours to handle The zero comes from upstream `/info`, not from us — GreenLeaf Prime returns `totalCulture: 1291.86` through the same code path on the same fetch. So the field is unreliable per server rather than always broken. ## Expected When `/info` reports 0 but milestone progress is non-zero, prefer the milestone maximum (or reconcile and flag). Right now `get_economy` publishes `total_culture: 0` as an economic KPI for a server with visible cultural output, and a reader has no way to know the field is untrustworthy. ## Minor, same surface - `world.animals: 0` on **both** servers tested, while `get_region` tracks live animal populations (Deer 248, Wolf 167, Bison 114). Same shape of problem — the `/info` field looks unpopulated and we pass it through unmarked. - GreenLeaf returns `daysUntilMeteor: -17` with `hasMeteor: false`; a negative countdown for a meteor that does not exist should probably be null.

coilyco-ops referenced this issue

2026-08-12 23:34:54 +00:00

Tracking: 2026-08-12 full-surface QA sweep of the eco MCP (22 tools, 23 findings) #240

coilyco-ops referenced this issue

2026-08-12 23:36:09 +00:00

Tracking: 2026-08-12 full-surface QA sweep of the eco MCP (22 tools, 23 findings) #240

coilyco-ops referenced this issue

2026-08-12 23:47:23 +00:00

Tracking: 2026-08-12 full-surface QA sweep of the eco MCP (22 tools, 23 findings) #240

coilyco-ops referenced this issue

2026-08-13 04:53:13 +00:00

world.animals is 0 on every server tested while get_region tracks live populations #246