The "How the world got here" section #193
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#193
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?
The existing 4 graphs are useless
A graph that would be useful: a vertical one that shows when a profession was unlocked (bright line, a color hue'd away from green) and when people take it (less bright, hue'd in the opposite direction)
Ux will be hard. Maybe the default shows all profession unlocks (not people) and the right side has buttons and when you click the button it slices to that profession + people. Mobile design will be hard though.
Design conclusion
Replace the current four progression sparklines and three rank lists with one vertical profession-history timeline. The primary task is to understand when each profession first appeared in the world, then inspect how people adopted one profession over time.
Interaction
Professionselect above the timeline. The timeline keeps full width and never requires horizontal scrolling.All profession unlocksis always available as the recovery action.?profession=so the state is linkable and browser navigation remains meaningful.Visual encoding
Data contract
The frontend must not derive this view from
citizens[].timeline. The server caps both citizen cards and their timelines, which can silently omit older adopters.The progression backend should derive
professionHistoryfrom the completeGainProfessionevent set before presentation caps:(profession, citizen).The wording stays first recorded unlock because the exporter proves the first observed
GainProfessionevent, not an independent official world-unlock event. If Eco exposes a stronger unlock event later, the data derivation can change without redesigning the interaction.States
Tracing profession history…status.GainProfessionexport showsNo profession gains recorded yet.No later adopters recorded.Validation requirement
Desktop and mobile behavior need browser evidence before implementation is accepted. The hosted Playwright service already exists, but the canonical native inventory currently omits it after a WIP removal. Restoring and verifying that surface is tracked in agentic-os-kai issue 808. eco-app should not add a repo-local Playwright MCP dependency.
Browser-validation correction
The validation dependency is not a single restored Playwright server.
playwright_localprovides the isolated headless browser that can inspect a localhost eco-app development surface at desktop and mobile widths.playwright_k3spreserves the hosted shared-context browser for durable shared state and cluster-reachable surfaces.The corrected setup is tracked in agentic-os-kai issue 808.