Social page: filter #-channels, relative-time column, hydrate names, fix Reputation graph, list every entry #74
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?
Depends on the page-gating ticket (name hydration is gated on the page becoming password/admin-only).
#(src/eco_mcp_app/social.py).player-a33033e6). Leaving them opaque is fine while the page is public (privacy), but once the page is password/admin-only, hydrate real names.frontend/src/lib/socialApi.ts,pages/Social.tsx,social.py).Files:
frontend/src/pages/Social.tsx,frontend/src/lib/socialApi.ts,src/eco_mcp_app/social.py.🔒 Reserved by
ward agent --driver claude— containerengineer-claude-eco-app-74on hostKAI-DESKTOP-TOWERis carrying this issue (reserved 2026-07-06T05:12:27Z). 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).
run seed context — what this run is carrying (ward#609)
coilyco-gaming/eco-app#74· branchissue-74· driverclaude· workflowdirect-mainengineer-claude-eco-app-74· wardv0.413.0· dispatched2026-07-06T05:12:27ZIssue body as seeded:
Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.413.0).
— Claude (she/her), via
ward agent🔓 Reservation released by
ward container reap— containereco-app(--driver claude) exited at the auth pre-launch gate without launching the agent (ward#222/#264/#609), so the hold it took is retracted. A plainward agentretry no longer needs--force.Gate: auth smoke test (claude credentials)
Recovery: Refresh the host claude login (re-run
claudeon the host to re-auth), then re-dispatch.error from the gate
— Claude (she/her), via
ward agent🔒 Reserved by
ward agent --driver claude— containerengineer-claude-eco-app-74on hostKAI-DESKTOP-TOWERis carrying this issue (reserved 2026-07-06T05:35:31Z). 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).
run seed context — what this run is carrying (ward#609)
coilyco-gaming/eco-app#74· branchissue-74· driverclaude· workflowdirect-mainengineer-claude-eco-app-74· wardv0.413.0· dispatched2026-07-06T05:35:31ZIssue body as seeded:
Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.413.0).
— Claude (she/her), via
ward agentWARD-OUTCOME: done - filtered #-channels, swapped the day column for relative time, delisted the sample cap so the feed shows every message, and made the reputation fold self-diagnose an empty graph; names stay redacted (hydration is gated on the still-public JSON plane).
Mostly smooth, with one honest wall: I couldn't reach the live exporter or the Eco source from the container (both admin-gated / private), so I couldn't confirm the real ReputationTransfer schema. Rather than guess a column name I can't verify, I made the graph explain its own emptiness - if transfers parse but every edge loses its giver/receiver, the surface now emits a warning naming the unrecognized party column, so one live load reveals the true header for a precise follow-up. That's the part I'm least certain "fixes" the graph: if the root cause is a wrong action name or column, the graph stays empty but now says why.
The
#-channel filter surprised me a little - the existing test fixtures treated#general/#tradeas the normal channels, but the module was built from guessed schemas (its own docstring admits it), so I trusted the issue over the fixtures and updated them. Filtering, relative-time, and list-every-entry are high-confidence and fully tested (12 social tests, 466 py + 81 fe green).Follow-ups worth filing: (1) confirm the live social-action headers and drop the diagnostic once the real ReputationTransfer schema is pinned; (2) if the reputation graph is still empty after that, the action name itself may be wrong; (3) the feed now renders every row unvirtualized - fine for a few thousand messages, worth revisiting if a cycle's chat log gets huge; (4) name hydration remains deferred because the page-password gate (#73) is a speed bump and
/preview/social.jsonstays public - real hydration needs the data plane itself gated.