A person likes a post in the feed: one press records a like, a second takes it back, and the post shows how many #8244

A person can now like a post in the feed. One press records a like, a second takes it back, and the post shows how many. The new tests, the typecheck, the gate and 603 feed, MCP-size, migration and OpenAPI tests all pass. I did not run the full suite, so the forge's check will be its first run. I did not start the app to try the live script by hand.

What changed

• Interaction kinds: liked and unliked are new kinds in INTERACTION_KINDS. The interaction.kind column has a CHECK constraint, so a migration (20261102160000-feed-likes, pinned) rebuilds the table with every row kept. It also adds an index on (item_id, viewer_id, id) for counting a post's likes.
• feed/likes.ts:

- likesOf counts each person once, using whichever of their liked or unliked rows is newest. - toggleLike records liked, or unliked if the viewer already likes it. - Rows are never edited.

• Feed API: POST /api/v1/feed/interactions with kind: "liked" is the toggle. It uses the same readInteraction access check, so an item the viewer can't read gets a 404. It answers {likes, liked}. unliked can't be sent directly (422). GET /api/v1/feed items carry likes and liked. The existing write-clock ETag already covers likes, so no cache change was needed.
• Affinity: liked weighs 2, the same as shared, and unliked weighs −2 so it cancels the like.
• Card: a Like button with the count, in a form that posts to POST /feed/like (new, web/studio/like.ts). It uses readForm (same-origin and rw scope), does the same toggle, and redirects back to /feed. With the live script the press updates aria-pressed and the count in place, then takes the server's count, and puts the old state back if the request fails. The label never changes, so nothing moves. If a card has likes but no liked (signed out), it shows "N likes" and no button.
• Docs and contract: the OpenAPI route summary and a "Likes" section in docs/FEED.md are updated.
• Tests: test/feed-like.test.ts covers like, unlike, two people counting separately, a 404 on an item the viewer can't read (no row left behind), unliked refused at the door, the affinity weights, the card markup, and the no-JavaScript form.

What I chose not to do

• No MCP tool and no ranking apps by likes, as the issue says.
• Likes don't go through the offline outbox, because replaying a toggle later could flip it the wrong way.
• The fast.ts selector named 1238 of 1830 test files for this diff. I ran the feed, MCP-size, migration, OpenAPI and contract tests instead.

How to try it On a preview, press Like on a feed card twice and the count goes up, then back down. With JavaScript off the same button reloads /feed with the new count. bun test test/feed-like.test.ts runs the new tests.

🤖 Generated with Claude Code

Closes #7751

A person can now like a post in the feed. One press records a like, a second takes it back, and the post shows how many. The new tests, the typecheck, the gate and 603 feed, MCP-size, migration and OpenAPI tests all pass. I did not run the full suite, so the forge's check will be its first run. I did not start the app to try the live script by hand.

What changed

• Interaction kinds: liked and unliked are new kinds in INTERACTION_KINDS. The interaction.kind column has a CHECK constraint, so a migration (20261102160000-feed-likes, pinned) rebuilds the table with every row kept. It also adds an index on (item_id, viewer_id, id) for counting a post's likes.
• feed/likes.ts:

- likesOf counts each person once, using whichever of their liked or unliked rows is newest. - toggleLike records liked, or unliked if the viewer already likes it. - Rows are never edited.

• Feed API: POST /api/v1/feed/interactions with kind: "liked" is the toggle. It uses the same readInteraction access check, so an item the viewer can't read gets a 404. It answers {likes, liked}. unliked can't be sent directly (422). GET /api/v1/feed items carry likes and liked. The existing write-clock ETag already covers likes, so no cache change was needed.
• Affinity: liked weighs 2, the same as shared, and unliked weighs −2 so it cancels the like.
• Card: a Like button with the count, in a form that posts to POST /feed/like (new, web/studio/like.ts). It uses readForm (same-origin and rw scope), does the same toggle, and redirects back to /feed. With the live script the press updates aria-pressed and the count in place, then takes the server's count, and puts the old state back if the request fails. The label never changes, so nothing moves. If a card has likes but no liked (signed out), it shows "N likes" and no button.
• Docs and contract: the OpenAPI route summary and a "Likes" section in docs/FEED.md are updated.
• Tests: test/feed-like.test.ts covers like, unlike, two people counting separately, a 404 on an item the viewer can't read (no row left behind), unliked refused at the door, the affinity weights, the card markup, and the no-JavaScript form.

What I chose not to do

• No MCP tool and no ranking apps by likes, as the issue says.
• Likes don't go through the offline outbox, because replaying a toggle later could flip it the wrong way.
• The fast.ts selector named 1238 of 1830 test files for this diff. I ran the feed, MCP-size, migration, OpenAPI and contract tests instead.

How to try it On a preview, press Like on a feed card twice and the count goes up, then back down. With JavaScript off the same button reloads /feed with the new count. bun test test/feed-like.test.ts runs the new tests.

🤖 Generated with Claude Code

A person can now like a post in the feed. One press likes it, a second press takes the like back, and each post shows how many people like it. The two failing checks are fixed. I ran the feed, schema-additive and front-door-timing tests, the gate, tsc and design-lint; they pass. I did not run the full suite, since the forge runs it on push.

What failed and why

• Migration not additive: the first version rebuilt interaction to widen its CHECK constraint, which the roll check rejects as a drop and a rename. Likes now live in a new table, feed_like (one row per person and post). The migration only adds, and its pin is regenerated.
• Ranking test: every feed item had gained likes and liked fields, so the page no longer equalled the ranking's slice. Items now carry those fields only once someone likes them, and absent means 0 and false. The card always draws the Like button.

What changed

• Press behaviour: the press now inserts or deletes the viewer's feed_like row (src/feed/likes.ts). POST /api/v1/feed/interactions with kind: "liked" and the scriptless form at POST /feed/like both go through it.
• Interaction kinds: liked and unliked are no longer interaction kinds. readInteraction takes the door's kind type as a generic so the API door can accept liked.
• Tests and docs: I rewrote test/feed-like.test.ts for the new table and updated docs/FEED.md.

What I chose not to do

• Affinity: likes no longer feed it, because that needs interaction kinds and would bring back the constraint rebuild. It can follow as a separate change.
• Signed-out count: the old count-only view for signed-out viewers is gone, because feed items always belong to a signed-in viewer.

To try it, press Like on a feed card twice and watch the count rise and fall.

🤖 Generated with Claude Code

I merged main into the likes branch and pushed it. The branch should merge cleanly again.

Three files conflicted, and I kept both sides in each:

• src/feed/rank.ts: FeedItem now has both step (from main) and likes/liked (from this pull).
• src/feed/feed.ts: a page's items now get settled, step and the like fields. likes and liked are still only added once someone has liked the post, as in the earlier fix.
• src/web/studio/feed.ts: the card shows the step link, then the reason line, then the Like button.

tsc, scripts/gate.ts and design-lint are clean. 222 tests pass across the feed, schema-additive, front-door-timing and step test files. I did not run the full suite, since the forge runs it on push.

All four blocking points and both smaller ones are addressed on the branch and pushed.

Checks: gate, tsc and bun scripts/design-lint.ts are clean. The feed, TUI feed, schema-additive and front-door-timing tests pass. The one exception is the real-browser test in test/composer-draft.test.ts: it fails here because the sandbox has no Chromium ("chromium did not offer a DevTools endpoint"), and this change doesn't touch it. The forge's check runs it.

1. Terminal door. In the Feed screen, l likes the post under the cursor and a second l takes it back. It goes through readInteraction and then toggleLike, as the page does. Rows show ♥ n for a post you like and ♡ n for one others like. I added a line to docs/FEED.md, and tests that a like in the terminal shows up in the page's feed and that an unreadable post can't be liked. A like made in the terminal reaches web viewers on their next live refresh, not instantly. The write moves the forge's write clock, which the live fragment polls, so I added no push channel.
2. Layout shift. The form is now .like instead of .bar. The count [data-likes] is inline-block at min-width: 3ch with tabular numerals, styled in feed_style.ts, and .like is documented in docs/design/areas/feed.md.
3. Tests added to test/feed-like.test.ts:

- GET /api/v1/feed returns likes and liked for each viewer, and omits them when nobody likes the post. - A cross-origin POST /feed/like returns 403 and writes nothing. - A signed-out POST /feed/like redirects to /signin and writes nothing. - The JSON answer of /feed/like is checked in both directions. - The live script's like function is run against stubs, covering the rollback to the old state with the "not saved" message, and the success path.

1. Count query. likesOf now does one GROUP BY item_id with COUNT(*) and SUM(viewer_id = ?).

Smaller points: I removed the title from the button, so aria-pressed is the only state signal, and I ran bun scripts/design-lint.ts.

I kept likes and liked absent from API items nobody has liked, because the ranking test requires the page to equal the ranking's slice. The docs say absent means 0 and false.

🤖 Generated with Claude Code

Three of the four failures are fixed and pushed. The fourth I couldn't reproduce, so I left it alone.

• Palette roster (3 tests): the Feed palette hint now ends "…issue or pull, l likes" because of the likes change, and test/palette-roster.test.ts still expected the old hint. I updated the three expected strings in the test. The test was out of date and the code was right. test/palette-roster.test.ts and test/tui-egress.test.ts now pass together (10 tests), and bun x tsc --noEmit is clean.
• "a site admin lists, grants and revokes through the actions": this test passes when I run test/tui-egress.test.ts here, three times in a row. I think it failed in the check as a flake. I haven't confirmed that. If it fails again on this push, the full log will say more.

I did not run the full suite or scripts/gate.ts this time.

The full-suite proof of this head is waiting: no check slot is spare. It starts when one frees.

Sentinel approved this head and left no blocking asks, so I changed nothing and pushed nothing. The full-suite check on this head hasn't started yet because no check slot is free. I haven't run anything since the last push, so the only proof so far is the earlier local runs.

What this pull does

• Web: a person presses like on a post in the feed, a second press takes it back, and the post shows its count. The scriptless form works with no JavaScript, and the live script rolls back if the request fails.
• API: likes toggle through the API. Cross-origin and signed-out requests are refused.
• Terminal: in the Feed screen, l goes through readInteraction and toggleLike, and the palette hint says so. The palette roster test was out of date and now names the Feed hint's new l likes.
• Counts: likesOf is one grouped query. The .like count is 3ch wide with tabular numerals, so the feed doesn't shift when it changes. The note is in docs/design/areas/feed.md.
• Docs: the how-to is in docs/FEED.md.

What I left alone

• A like made in the terminal reaches web viewers on their next live refresh, through the write clock, not instantly. Sentinel noted this as non-blocking. I haven't built a push path for it.

How to try it

• Open the feed on the preview at https://lab--8244--forge-trevato-apps.open-platform.sh and press like twice. The first press records a like and the second takes it back. Or press l in the terminal's Feed screen.

🤖 Generated with Claude Code