Light up the citizen id→name association: deploy CitizensApiController + verify user.Id matches the exporter Citizen id [restart-gated] #65
Labels
No labels
burndown-2026-06
burndown-2026-08
headless
autonomy
async-consult
autonomy
epic
autonomy
headless
autonomy
live-collab
c#
priority
P0
priority
P1
priority
P2
priority
P3
priority
P4
role/advocate
role/director
role/exec
role/frontend
role/gamedev
role/human
role/platform
role/qa
role/science
role/sysadmin
state
ambient
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
coilyco-gaming/eco-app#65
Loading…
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 citizen id -> name join built in #5 (closed) is not actually lit up in production. The machinery exists - realignment-tolerant row parsing plus the join via a new jobs-mod endpoint
/api/v1/citizens(CitizensApiController.cs, with aCitizen #<id>fallback) - but two gaps keep it from resolving real names on the live server, and neither was tracked:user.Idis the same numeric the action exporter emits forCitizen/Buyer/Seller/ShopOwner- was never confirmed against live data. If it diverges, the join returns empty and everything degrades toCitizen #<id>labels. Their recommended "verify against a live cycle" follow-up was never filed./api/v1/citizensships inside the EcoJobsTracker DLL, but #31 reports the DLL on kai-server is still a stale pre-#3 build that predatesCitizensApiControllerentirely. So the endpoint is not serving on the live server - the join has nothing to call.Why this is high-leverage
Every per-citizen view depends on this resolving: #12 by-citizen distributions, #17 crafter leaderboards, #61 civics (who voted/won), #64 progression, plus #6 trade names and #50 store owners. Until this is lit up, all of them silently render
Citizen #<id>instead of names - graceful (no crash) but the difference between a real dashboard and a wall of numbers.Tasks
CitizensApiController(and the #31lastSeenfield) to kai-server so/api/v1/citizensserves. Coordinate with #31 - one mod push should carry both./api/v1/citizensuser.Idmatches the numeric the action exporter emits forCitizen/Buyer/Seller/ShopOwner. Probe per the dataset how-to. If it diverges,CitizenDtoneeds the correct/extra identifier field.Citizen #<id>.Restart constraint
This is restart-gated - it needs the mod deployed (a DLL push + server restart), so it lands in the next-restart-window bucket alongside #31 and #55 (the stores-mod activation), not on the no-restart track. The verify step (task 2) cannot run until the endpoint serves.
Acceptance
/api/v1/citizensserves live on kai-server (one push carrying #5'sCitizensApiController+ #31'slastSeen).user.Id== exporter-Citizen-id match is verified on a live cycle and documented; if divergent, the DTO carries the correct identifier.Citizen #<id>.Refs
Built by #5 (closed). Mod rollout sibling #31. Survey #7. Consumers: #6, #12, #17, #50, #61, #64. Origin: eco-app director session, 2026-07-05, flagged by Kai.
Verified complete from the live public data planes on 2026-07-25 without inspecting player values.
Citizen #<id>fallback labels.That is end-to-end evidence that the deployed CitizensApiController is serving, its identifier matches the exporter ids used by the consumers, and real names resolve on live per-citizen surfaces. The fallback should remain as degradation behavior for an unavailable mod endpoint. Closing the rollout verification issue.