A pull that starts waiting on a team's review shows one line in that team's members' feed #10166

A pull that starts waiting on a named team's review now puts one line in the feed of that team's members: "acme/demo#12 waits on Design's review". The new tests pass, and tsc, scripts/gate.ts and the related feed, audience and team-gate tests are green. I did not run the full suite or scripts/design-lint.ts, and I did not call keep_plan; I had no such tool here, so the issue has no plan.

What changed

• Emitting the event: src/actions/team_waits.ts (new) has announceTeamWaits. It asks teamsHolding which teams hold the pull and compares that with the newest pull.team_waiting or pull.team_answered event for that pull and team.

- A team that holds with no standing "waiting" line gets one pull.team_waiting event, with the number, team slug and team name. - A team that no longer holds, such as after its approval, gets pull.team_answered, so a later re-hold is news again.

• When it runs: src/actions/pulls.ts calls it after a local pull opens and after submitReview records a verdict.
• Who sees it: src/feed/items.ts drops the pull.team_waiting event for anyone not on the team. Repository read access is still enforced by the usual event visibility. The line carries the pull's link, and the team name is clipped and escaped when the page renders.
• Event classification: both new kinds are listed for readers in src/core/event_audience.ts, with wording in src/design/activity.ts.

Tests (test/feed-team-waits.test.ts)

• A member sees the line once.
• A non-member sees nothing.
• A comment review does not repeat it.
• The team's approval ends the wait.
• A team name containing a script tag comes out escaped on /feed.

What I chose not to do

• Re-holds: a push that makes an old approval stale does not announce a new wait. I only announce at open and at review time.
• Naming a team on an open pull's issue: nameTeams does not announce either.
• Mirrored pulls: opening a pull through an origin does not announce.
• Other readers: other readers of the repository see the wait on the repository's events list (/:owner/:name/events) and in the activity rail, but not in the feed.
• Events list: both new kinds are treated as reader events, so they show on that page.

To try it: name a team on an issue, open a pull that closes it, then read /feed as a member of that team. Team members are agents today, so the test seats the person directly in the database.

Closes #10164

A pull that starts waiting on a named team's review now puts one line in the feed of that team's members: "acme/demo#12 waits on Design's review". The new tests pass, and tsc, scripts/gate.ts and the related feed, audience and team-gate tests are green. I did not run the full suite or scripts/design-lint.ts, and I did not call keep_plan; I had no such tool here, so the issue has no plan.

What changed

• Emitting the event: src/actions/team_waits.ts (new) has announceTeamWaits. It asks teamsHolding which teams hold the pull and compares that with the newest pull.team_waiting or pull.team_answered event for that pull and team.

- A team that holds with no standing "waiting" line gets one pull.team_waiting event, with the number, team slug and team name. - A team that no longer holds, such as after its approval, gets pull.team_answered, so a later re-hold is news again.

• When it runs: src/actions/pulls.ts calls it after a local pull opens and after submitReview records a verdict.
• Who sees it: src/feed/items.ts drops the pull.team_waiting event for anyone not on the team. Repository read access is still enforced by the usual event visibility. The line carries the pull's link, and the team name is clipped and escaped when the page renders.
• Event classification: both new kinds are listed for readers in src/core/event_audience.ts, with wording in src/design/activity.ts.

Tests (test/feed-team-waits.test.ts)

• A member sees the line once.
• A non-member sees nothing.
• A comment review does not repeat it.
• The team's approval ends the wait.
• A team name containing a script tag comes out escaped on /feed.

What I chose not to do

• Re-holds: a push that makes an old approval stale does not announce a new wait. I only announce at open and at review time.
• Naming a team on an open pull's issue: nameTeams does not announce either.
• Mirrored pulls: opening a pull through an origin does not announce.
• Other readers: other readers of the repository see the wait on the repository's events list (/:owner/:name/events) and in the activity rail, but not in the feed.
• Events list: both new kinds are treated as reader events, so they show on that page.

To try it: name a team on an issue, open a pull that closes it, then read /feed as a member of that team. Team members are agents today, so the test seats the person directly in the database.

The check failed because no commit message had a Why now: or Try: line. I pushed an empty commit that adds both. bun scripts/gate.ts now passes locally and the push went through. I haven't seen the forge's rerun of the check yet.

The code is unchanged from the earlier push. A pull that starts waiting on a named team's review still puts one line in that team's members' feed, and the team's approval ends it. tsc and the new tests passed on the first push, and I did not rerun them this time.

• Why now: the issue asks that a team be told once, in the feed it already reads, when a pull starts waiting on its review.
• Try: open /feed as a member of a team named on a pull's closed issue, after the pull opens.

Naming a team on an issue that an open pull already closes now announces the wait. The gate, tsc and the new and team tests pass locally, and the push is up. I did not run the full suite.

Changes

1. Late naming: nameTeams calls announceIssueTeamWaits (src/actions/team_waits.ts), which runs announceTeamWaits for every open pull whose body closes that issue. A test names the team after the pull exists and checks that exactly one line is told.
2. Private repo and the answer:

- Private repo: a team member with no read access to a private repo sees no line, and the test also checks the wait was told. I could not write the positive case I wanted: the feed's SQL visibility (repoVisible) doesn't count crew membership as read access. Even a team member on that repo's crew (pike) gets no line there. Team members can only be agents (saveTeam rejects anyone else), so a private-repo member can never see a line today. I documented that and did not widen the feed's visibility. - Answer kind: a second test checks that pull.team_answered never becomes a feed post.

1. Docs: docs/features/team-waits.md is new. The terminal's Feed screen goes through readFeed, which calls candidatesFor, so the terminal, /feed and the MCP feed tool all say the same thing.
2. Escaping test: it now goes through the real path (open a pull, read /feed as the member with a bearer token) and asserts the page contains Design's review and not the raw apostrophe. There is no raw INSERT. I did not use a hostile team name. Team names come from the seeding migration and no door lets anyone set them, so a hostile one can't occur through a real path. I chose the apostrophe in "Design's" because escaping changes it.

Not done

• A push that makes an approval stale and mirrored pulls are still not announced. The docs say so. A stale-approval push would need a hook on the head-update path, which is a bigger change than this issue.
• Narrowing the audience: I stated the wider audience in the docs and did not narrow it. Making the kind admin-only would hide it from the feed too, because the feed filters through audienceFilter. Narrowing it properly needs a per-viewer audience class in event_audience.ts, so I left it for a separate change. As it stands, the pull number and the team's name also show to every reader on /:owner/:name/events and in the activity rail.

Try it: name a team on an issue, open a pull that says Closes #N, and open /feed as a member of that team. Naming the team after the pull is open now works too.

When a pull first becomes held by a named team, one pull.team_waiting event goes out. Only members of that team who can read the repository see "owner/repo#12 waits on Design's review", in the feed and on every other surface that lists events.

• Audience (src/core/event_audience.ts): pull.team_waiting and pull.team_answered are no longer reader kinds. They have a new team audience: active members of payload.team only, not the repository's other readers or its admins. audienceFilter applies it, and the feed, /:owner/:name/events, API and MCP events, the event streams and the activity rail all go through audienceFilter. The thread timeline never shows these kinds.
• Members who read a private repository (src/feed/items.ts, src/core/events.ts): the feed's own window comes from the owner and org visibility query, which leaves out crew members of a private repository. teamWaitsHeard adds the viewer's team waits from listTeamEventsFor, keeping only repositories that pass canRead (the same check the pull's page uses) and then audienceFilter. The terminal Feed screen reaches candidatesFor through readFeed, so it says the same thing as /feed and MCP feed.
• When it is said (src/actions/team_waits.ts): after a local pull opens, after a review is recorded, and when nameTeams names a team on an issue that open pulls close. It is said once per pull and team; the team's current approval ends the wait with pull.team_answered, which never shows in the feed, so a later hold is news again.
• Query cost: checking what was last said is one read per call, and naming teams reads only open pulls whose body contains #N, at most 50. Both queries run on the event_kind_seq index (checked with EXPLAIN QUERY PLAN).
• Not done: a push that makes an old approval stale does not re-announce, and pulls opened through a mirror's origin are not announced.
• Escaping: the test covers only the apostrophe in "Design's", which the page renders as Design's. < > & and " can't be tested through a real path: the line is built from the repository's validated slug path and the team's name, and team names are set only by the seeding migration. No door renames a team.

Tests are in test/feed-team-waits.test.ts:

• members see the line once, non-members don't, and a comment review doesn't repeat it;
• naming the team after the pull is open announces it;
• on a private repository, a crew member who reads it sees the line and a team member who can't read it doesn't;
• on the events list, the owner and a non-member reader of a public repository see nothing;
• the answer never becomes a post;
• the escaping check above.

Docs are in docs/features/team-waits.md. The gate and tsc pass, and so do the related team, feed and events tests; the full suite was not run here.

To try it: name a team on an issue, open a pull that says Closes #N, and open /feed as a member of that team. /:owner/:name/events read by anyone not on the team shows no wait.

🤖 Generated with Claude Code

When a pull first becomes held by a named team, one pull.team_waiting event goes out. Only that team's members who can read the repository see "owner/repo#12 waits on Design's review", in the feed and on every surface that lists events. While the pull stays held nothing more is said. The team's approval ends the wait with pull.team_answered, which is never a feed post, so a later hold is news again.

• Audience (src/core/event_audience.ts): both kinds have a team audience, which admits only active members of payload.team. The repository's other readers and its admins don't see them. The events list, the API and MCP events, the streams and the activity rail all filter through audienceFilter, so they apply it too. Merging main brought in its new writers audience (adapter.sync_failed); both audiences are kept side by side.
• Private repositories (src/feed/items.ts, src/core/events.ts): the feed only reads events from repositories visible to the viewer by owner and org access. That leaves out crew members of a private repository. For them, the feed adds their team waits through listTeamEventsFor, filtered by canRead (the check the pull page uses) and then by audienceFilter. The web /feed, MCP feed and the terminal's Feed screen all build from candidatesFor, so they show the same line.
• When it is announced (src/actions/team_waits.ts): after a local pull opens, after a review is recorded, and when nameTeams names a team on an issue that open pulls close. The check for what was already said is one query on the kind index. Naming teams reads at most the 50 newest open pulls whose body contains #N.
• Not announced: a push that makes an old approval stale, and pulls opened through a mirror's origin.
• Escaping: only the apostrophe is tested (Design's). The line is built from the repository's validated path and the team's name. Team names are set only by the migration that seeds them, so no real path can put < > & or " in one.
• Tests (test/feed-team-waits.test.ts), all passing with the gate and tsc after the merge:

- Team members see the line once, others don't, and a comment review doesn't repeat it. - Naming a team on an already-open pull's issue announces the wait. - On a private repository, a team member on its crew sees the line and a team member who can't read it doesn't. - On the events list, a reader who isn't on the team, the owner included, sees nothing. - The answer is never a feed post.

• How-to: docs/features/team-waits.md.

To try it: name a team on an issue, open a pull with Closes #N, then open /feed as a member of that team. /:owner/:name/events shows no wait to anyone who isn't on the team.

🤖 Generated with Claude Code