Social page: filter #-channels, relative-time column, hydrate names, fix Reputation graph, list every entry #74

Closed
opened 2026-07-06 05:11:16 +00:00 by coilysiren · 4 comments
Owner

Depends on the page-gating ticket (name hydration is gated on the page becoming password/admin-only).

  • API: filter out chats from channels whose name starts with # (src/eco_mcp_app/social.py).
  • Player names not hydrated (e.g. player-a33033e6). Leaving them opaque is fine while the page is public (privacy), but once the page is password/admin-only, hydrate real names.
  • "Reputation graph" section isn't hydrating data - fix (frontend/src/lib/socialApi.ts, pages/Social.tsx, social.py).
  • "day" column isn't useful - replace with relative time (e.g. "1 hour ago").
  • Data volume: currently ~20 entries, near useless. List every entry.

Files: frontend/src/pages/Social.tsx, frontend/src/lib/socialApi.ts, src/eco_mcp_app/social.py.

Depends on the page-gating ticket (name hydration is gated on the page becoming password/admin-only). - **API: filter out chats from channels whose name starts with `#`** (`src/eco_mcp_app/social.py`). - **Player names not hydrated** (e.g. `player-a33033e6`). Leaving them opaque is fine while the page is public (privacy), but **once the page is password/admin-only, hydrate real names**. - **"Reputation graph" section isn't hydrating data** - fix (`frontend/src/lib/socialApi.ts`, `pages/Social.tsx`, `social.py`). - **"day" column isn't useful** - replace with **relative time** (e.g. "1 hour ago"). - **Data volume**: currently ~20 entries, near useless. **List every entry.** Files: `frontend/src/pages/Social.tsx`, `frontend/src/lib/socialApi.ts`, `src/eco_mcp_app/social.py`.
Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-eco-app-74 on host KAI-DESKTOP-TOWER is carrying this issue (reserved 2026-07-06T05:12:27Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

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)
  • Resolved: coilyco-gaming/eco-app#74 · branch issue-74 · driver claude · workflow direct-main
  • Run: engineer-claude-eco-app-74 · ward v0.413.0 · dispatched 2026-07-06T05:12:27Z
  • Comment thread: 0 included in the pre-flight read, 0 stripped (ward's own automated comments).

Issue body as seeded:

Depends on the page-gating ticket (name hydration is gated on the page becoming password/admin-only).

- **API: filter out chats from channels whose name starts with `#`** (`src/eco_mcp_app/social.py`).
- **Player names not hydrated** (e.g. `player-a33033e6`). Leaving them opaque is fine while the page is public (privacy), but **once the page is password/admin-only, hydrate real names**.
- **"Reputation graph" section isn't hydrating data** - fix (`frontend/src/lib/socialApi.ts`, `pages/Social.tsx`, `social.py`).
- **"day" column isn't useful** - replace with **relative time** (e.g. "1 hour ago").
- **Data volume**: currently ~20 entries, near useless. **List every entry.**

Files: `frontend/src/pages/Social.tsx`, `frontend/src/lib/socialApi.ts`, `src/eco_mcp_app/social.py`.

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

<!-- ward-agent-reservation --> 🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-eco-app-74` on host `KAI-DESKTOP-TOWER` is carrying this issue (reserved 2026-07-06T05:12:27Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides. **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). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-gaming/eco-app#74` · branch `issue-74` · driver `claude` · workflow `direct-main` - **Run:** `engineer-claude-eco-app-74` · ward `v0.413.0` · dispatched `2026-07-06T05:12:27Z` - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). **Issue body as seeded:** ``` Depends on the page-gating ticket (name hydration is gated on the page becoming password/admin-only). - **API: filter out chats from channels whose name starts with `#`** (`src/eco_mcp_app/social.py`). - **Player names not hydrated** (e.g. `player-a33033e6`). Leaving them opaque is fine while the page is public (privacy), but **once the page is password/admin-only, hydrate real names**. - **"Reputation graph" section isn't hydrating data** - fix (`frontend/src/lib/socialApi.ts`, `pages/Social.tsx`, `social.py`). - **"day" column isn't useful** - replace with **relative time** (e.g. "1 hour ago"). - **Data volume**: currently ~20 entries, near useless. **List every entry.** Files: `frontend/src/pages/Social.tsx`, `frontend/src/lib/socialApi.ts`, `src/eco_mcp_app/social.py`. ``` Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.413.0). </details> <!-- ward-agent-signature --> — Claude (she/her), via `ward agent`
Author
Owner

🔓 Reservation released by ward container reap — container eco-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 plain ward agent retry no longer needs --force.

Gate: auth smoke test (claude credentials)

Recovery: Refresh the host claude login (re-run claude on the host to re-auth), then re-dispatch.

error from the gate
auth smoke test: claude -p rejected the credentials (exit 1) - they are unusable in-container (ward#222). Refresh the host claude login (re-run 'claude' on the host) and relaunch; WARD_SMOKE_TEST_SKIP=1 bypasses.

— Claude (she/her), via ward agent

<!-- ward-agent-reservation-released --> 🔓 Reservation released by `ward container reap` — container `eco-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 plain `ward agent` retry no longer needs `--force`. **Gate:** auth smoke test (claude credentials) **Recovery:** Refresh the host claude login (re-run `claude` on the host to re-auth), then re-dispatch. <details><summary>error from the gate</summary> ``` auth smoke test: claude -p rejected the credentials (exit 1) - they are unusable in-container (ward#222). Refresh the host claude login (re-run 'claude' on the host) and relaunch; WARD_SMOKE_TEST_SKIP=1 bypasses. ``` </details> <!-- ward-agent-signature --> — Claude (she/her), via `ward agent`
Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-eco-app-74 on host KAI-DESKTOP-TOWER is carrying this issue (reserved 2026-07-06T05:35:31Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

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)
  • Resolved: coilyco-gaming/eco-app#74 · branch issue-74 · driver claude · workflow direct-main
  • Run: engineer-claude-eco-app-74 · ward v0.413.0 · dispatched 2026-07-06T05:35:31Z
  • Comment thread: 1 included in the pre-flight read, 1 stripped (ward's own automated comments).

Issue body as seeded:

Depends on the page-gating ticket (name hydration is gated on the page becoming password/admin-only).

- **API: filter out chats from channels whose name starts with `#`** (`src/eco_mcp_app/social.py`).
- **Player names not hydrated** (e.g. `player-a33033e6`). Leaving them opaque is fine while the page is public (privacy), but **once the page is password/admin-only, hydrate real names**.
- **"Reputation graph" section isn't hydrating data** - fix (`frontend/src/lib/socialApi.ts`, `pages/Social.tsx`, `social.py`).
- **"day" column isn't useful** - replace with **relative time** (e.g. "1 hour ago").
- **Data volume**: currently ~20 entries, near useless. **List every entry.**

Files: `frontend/src/pages/Social.tsx`, `frontend/src/lib/socialApi.ts`, `src/eco_mcp_app/social.py`.

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

<!-- ward-agent-reservation --> 🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-eco-app-74` on host `KAI-DESKTOP-TOWER` is carrying this issue (reserved 2026-07-06T05:35:31Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides. **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). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-gaming/eco-app#74` · branch `issue-74` · driver `claude` · workflow `direct-main` - **Run:** `engineer-claude-eco-app-74` · ward `v0.413.0` · dispatched `2026-07-06T05:35:31Z` - **Comment thread:** 1 included in the pre-flight read, 1 stripped (ward's own automated comments). - included: @coilysiren (2026-07-06T05:13:01Z) - stripped: @coilyco-ops (2026-07-06T05:12:33Z) **Issue body as seeded:** ``` Depends on the page-gating ticket (name hydration is gated on the page becoming password/admin-only). - **API: filter out chats from channels whose name starts with `#`** (`src/eco_mcp_app/social.py`). - **Player names not hydrated** (e.g. `player-a33033e6`). Leaving them opaque is fine while the page is public (privacy), but **once the page is password/admin-only, hydrate real names**. - **"Reputation graph" section isn't hydrating data** - fix (`frontend/src/lib/socialApi.ts`, `pages/Social.tsx`, `social.py`). - **"day" column isn't useful** - replace with **relative time** (e.g. "1 hour ago"). - **Data volume**: currently ~20 entries, near useless. **List every entry.** Files: `frontend/src/pages/Social.tsx`, `frontend/src/lib/socialApi.ts`, `src/eco_mcp_app/social.py`. ``` Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.413.0). </details> <!-- ward-agent-signature --> — Claude (she/her), via `ward agent`
Author
Owner

WARD-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/#trade as 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.json stays public - real hydration needs the data plane itself gated.

WARD-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`/`#trade` as 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.json` stays public - real hydration needs the data plane itself gated.
Sign in to join this conversation.
No description provided.