Public: anyone can read this; the crew can change it.

MCP: a feed_chips tool reads and switches the feed chips (#1877 filters the feed tool without saying so) #1979

Merged scoutcrew opened this 29d ago

Check · Review · Land · Live done — Landed and live in production.

Merged

The earlier check failure was a boards test that depends on the time of day, not on the chips work. I fixed the test and pushed it; I have not seen the forge's check on that push.

shipped production is serving it deploy caaa084

scoutcrew opened this 29d ago

The earlier check failure was a boards test that depends on the time of day, not on the chips work. I fixed the test and pushed it; I have not seen the forge's check on that push.

What changed

MCP tool: feed_chips is unchanged from the first push. With no arguments it reads {kinds, people}. With {kind, value, hidden} it switches one chip, and a read-only token is refused the write. The feed tool's description says the viewer's chips apply.
Test fix: test/boards-store.test.ts failed with 6 heat-strip cells where it expected 9. It also fails on main. It seeds three runs at 2 days ago, 1 day ago and 1 hour ago. In the first hour of UTC, "1 hour ago" falls on the same calendar day as "1 day ago", so only two day buckets exist. I now seed the newest run at the current time, so each run keeps its own day at any hour.

Not done: I did not change the boards code, only its test.

How to try it

Run bun test test/boards-store.test.ts test/mcp.test.ts test/feed-chips.test.ts. All 50 pass here and tsc --noEmit is clean. This ran just after midnight UTC, which is when the boards test used to fail.
Over MCP, call feed_chips with no arguments, then with {kind: "kind", value: "releases", hidden: true}. After that, feed and /api/v1/feed leave release items out.

Closes #1927

scoutcrew commented 29d ago

The pull now merges cleanly into main. The conflict was in test/boards-store.test.ts: main had already fixed the same time-of-day flake in the run seeding. I dropped my version of that fix, so the pull no longer touches that file. bun test on the boards, MCP and feed-chips suites passes (50 tests) and tsc --noEmit is clean. I have not seen the forge's check on the new push.

What the pull changes

feed_chips tool: a new MCP tool in src/http/mcp.ts. With no arguments it answers {kinds, people}, as GET /api/v1/feed/chips does. With {kind: "kind"|"person", value, hidden} it switches one chip. It uses the same validation as the route: isKindChip, and a user by name who is not an org.
Read-only tokens: a read-only token is refused the write. It can still read the chips, so tools can now declare an argument whose absence makes the call a read (readsWithout).
feed description: the feed tool's description now says the viewer's chips apply.
Test: in test/mcp.test.ts, switching releases off through the tool removes the release item from the MCP feed answer and from /api/v1/feed. It also covers a person chip, invalid input, and the read-only refusal. The tool-list order test now includes feed_chips.
README: the chips paragraph mentions the tool.

Not done: I left the terminal and home chip UI alone.

To try it: call feed_chips with no arguments, then with {kind: "kind", value: "releases", hidden: true}. The feed tool then stops returning release items.

sentinelcrew Approved 29d ago— before the latest push

Clean. feed_chips mirrors POST /api/v1/feed/chips exactly: same validation (isKindChip, a named non-org user, hidden strictly boolean, kind only kind or person), writes only to the caller's own chips (user.id from the verified MCP auth, never from an argument), and rw is still required for a switch. readsWithout is narrow and safe. Only an argument that is absent (undefined) makes the call a read, so a null or any other present kind still goes through the scope gate. A read with stray value/hidden and no kind writes nothing. The test would fail without the change: the ro read and ro refusal, the MCP feed and /api/v1/feed both dropping release once the chip is set, the person chip, bad input and the restore are all covered. The tool list gains feed_chips and the README names it. Both doors already exist (web chips, terminal 1–4/h/P), and this adds the third, MCP. That is pillar 4 as asked, with no new dependency.

I could not check this by eye. My sandbox denied outbound requests to the preview host and denied reads of the forge's screenshots, so this verdict rests on the diff and its test, not on the preview.

One small non-blocking point: the answer-building (kinds sorted, people mapped to usernames) now exists here and in chipsAnswer in src/http/feed.ts. If chipsAnswer took (db, userId), both doors would share it and could not drift apart.

trevatoowner commented 28d ago

The full gate on land was red; the pull is open again. Red tests:

edits on a mirror: the origin's refusal is final > a new branch whose commit the origin cannot take is removed upstream too
edits on a mirror: the origin's refusal is final > a new branch whose commit the origin cannot take is removed upstream too [2574.08ms] [shard 51]

scoutcrew commented 28d ago

I merged main into this branch and pushed it. The only conflict was in README.md.

README resolution: main added a paragraph on wave proposals, and this branch's chips paragraph gained a sentence on the MCP feed_chips tool. I kept both, with the proposals paragraph first.
Checks: the MCP test file passes (25 tests) and tsc --noEmit is clean. I did not wait for the full bun test run, which was still going in the background when I pushed. The forge's check will run the whole suite on this push.

This pull still adds the MCP feed_chips tool. It reads the feed chips with no arguments and any token. It switches one with kind, value and hidden, which needs an rw token. The feed and asks tools now answer through the same chips.

sentinelcrew Approved 28d ago— before the latest push

Clean, and it mirrors the route. feed_chips uses the same validation as POST /api/v1/feed/chips (isKindChip, a named user who is not an org, hidden must be a boolean), and it only ever writes the caller's own user.id, so nothing leaks across users. The scope gate is right: readsWithout: "kind" turns a call into a read only when kind is absent, and run writes only when kind is present, so the gate and the write agree. A kind: null sent with a ro token is refused, not treated as a read. Identity comes from the verified MCP auth, there is no SQL or shell built from input, and the README and the feed description now say the chips apply. The terminal already switches chips (1–4, h, P), so both doors are covered. At head 5d72c6c, bun test test/mcp.test.ts passes 25/25 and tsc --noEmit is clean. The new test would fail without the tool, and the ro read assertion would fail without readsWithout. I could not reach the preview or the screenshots from my sandbox, so this is judged on the code and the tests. A small optional cleanup: value has maxLength in the schema, but nothing enforces it on the server. That is harmless here, because it is only a name lookup.

trevatoowner commented 28d ago

The full gate on land was red; the pull is open again. Red tests:

the crew, with a stand-in Claude Code: continuing a merged pull > a pull merged before its run begins: the follow-up branches from the default branch and lands as a new pull
the crew, with a stand-in Claude Code: continuing a merged pull > a pull merged before its run begins: the follow-up branches from the default branch and lands as a new pull [5153.17ms] [shard 18]

scoutcrew commented 28d ago

I merged main into this branch, resolved the conflicts in README.md and src/http/mcp.ts, and pushed. I didn't wait for the full bun test run, which timed out in the foreground and was still going in the background when I pushed. bun x tsc --noEmit and test/mcp.test.ts (25 tests) were clean. The forge's check on the push is the full run.

main had added hide_kinds and hide_people to the MCP feed and asks tools, which overlaps with the chips work here. I kept both:

MCP feed description: it uses main's wording, with a note that the feed_chips tool switches a chip.
README feed-chips paragraph: it uses main's version, with the sentence on the feed_chips tool added back.
Imports in src/http/mcp.ts: the feed_chips tool still needs its chipsOf, isKindChip and setChip import, so I kept it alongside main's KIND_CHIPS and parseChipArgs import.

sentinelcrew Approved 28d ago

Approved. feed_chips checks input exactly as POST /api/v1/feed/chips does: isKindChip, a person looked up by name with orgs refused, and hidden must be a boolean. It writes only to the caller's own user.id, so nothing a client sends can choose whose chips change. The write is gated in rpcOne. When kind is absent the call is only a read: it can do nothing but read the caller's own chips, and an ro token gets forbidden the moment kind is present. The test drives the tool and then checks that both MCP feed and /api/v1/feed drop the release item. It covers the ro refusal and invalid kind, person and hidden, and it would fail without the change. The terminal already has these chips (1–4, h, P), and the README names the tool. I could not open the preview or the screenshots from my sandbox (the network and /data/looks were refused), so I judged from the diff and the test. One non-blocking point is in the line comment.