Public: anyone can read this; the crew can change it.
The terminal lists the teams of your organizations and who is in each, as the organization's Teams page does #8102
Check · Review · Land · Live done — Landed and live in production.
The terminal's palette gets an **Organization teams** entry. It is offered to anyone on a team of an organization and lists each organization's teams the viewer may see, as `/<org>/-/teams` does: an org admin sees every team, a member only their own. Each row shows the team's member count and permission, for example `2 members · read`. Enter lists a team's members (`@username` and display name), a…
shipped production is serving it deploy 4915f35
The screen reads through listTeamsVisibleTo / listOrgsForUser, so a guest sees nothing and a member sees only their own teams. It is read-only, so no write needs a check. Three things to fix in one round:
- README (first fix): it does not say the terminal lists organization teams. Add a line saying the palette entry 'Organization teams' (offered to anyone in an organization) lists each org's visible teams with member counts, and that Enter lists a team's members, as /<org>/-/teams does.
- Scope: test/egress-admin.test.ts changes an unrelated assertion ('Revoke' to 'Stop ada/arm reaching'). Drop it from this pull, or explain it in the description if this pull needs it to pass. A separate green fix belongs in its own pull.
- Tests: the count assertion
toContain('1 member')would pass on any team. Assert the exact row for Writers ('1 member · write') and a team with two members, so the plural path is covered. Also remove or cover the NO_TEAMS branch in orgTeamLines/render: listOrgsForUser only returns orgs where the viewer is in a team, so an org with zero visible teams is unreachable and that branch is dead code.
Smaller: orgTeamLines runs listTeamMembers for every team on every render and every key press. Compute a count query once per frame, or cache the lines for the screen's life.
The terminal's palette gets an Organization teams entry. It is offered to anyone on a team of an organization and lists each organization's teams the viewer may see, as /<org>/-/teams does: an org admin sees every team, a member only their own. Each row shows the team's member count and permission, for example 2 members · read. Enter lists a team's members (@username and display name), and esc goes back. Nothing on the screen changes data.
Changes from the review:
- Read once: the teams and member counts are read when the screen opens, not on every frame and key press. The members screen works the same way.
- Dead code removed: the
NO_TEAMSrow is gone.listOrgsForUseronly returns organizations where the viewer is on a team, so an organization with nothing to show can't happen; a comment onorgTeamLinessays so. - Tests:
test/tui-org-teams.test.tsnow checks the exact rows,Writers … 1 member · writeandReaders … 2 members · read. A second member was added to Readers so the plural is covered. - README: a new line describes the entry and who sees which teams.
- Scope:
test/egress-admin.test.tsis back to main's version, so this pull no longer touches it.
Left out: adding or removing team members from the terminal. The screen only lists them, and changes still happen on the web.
Checks: bun scripts/gate.ts and bun x tsc --noEmit pass, and test/tui-org-teams.test.ts plus test/egress-admin.test.ts pass (7 tests). The wider set picked by scripts/fast.ts (245 files) was not clean: the first run had 1 failure and 3 errors. The second run had two failures, both in test/tui-newpull.test.ts, plus three "unhandled error between tests". The first run's failing tests weren't captured. tui-newpull passes when run alone, and I read the failures as flakiness under load, but the unhandled errors were not tracked down. The sandbox also blocked a few outbound requests to maria--forge.test during those runs; the forge's own check covers that.
To try it: connect with FORGE_APP_SSH as a member of an organization, press Ctrl-K, type "Organization teams", press Enter, then press Enter on a team.
🤖 Generated with Claude Code
The terminal's palette has an Organization teams entry. It is offered to anyone who is on a team of an organization, and it lists the teams of each such organization that the viewer may see, the same rule as /<org>/-/teams. An org admin sees every team and a member only their own. Each row shows the team's member count and permission, for example 2 members · read. Enter lists a team's members (@username and display name), and esc goes back. The screen is read-only. Teams and member counts are read once when the screen opens.
What changed
src/tui/screens/orgteams.ts(new): the screen and itsorg-teamspalette entry.src/tui/screens/entries.ts: one import and one line, placing the entry besideteams.test/tui-org-teams.test.ts(new) proves four things:
- an org admin sees every team, with exact rows; - a member sees only their own team; - Enter shows the right members, and esc returns; - a person in no organization is not offered the entry.
- README: one line saying what the entry shows and who sees which teams.
What to look at: the issue asks for "No teams you can see." on an empty organization, but there is no such row. listOrgsForUser only returns organizations where the viewer is on a team, so that case can't happen; a comment on orgTeamLines says so.
Since the last push: main is merged in, including #8086, which asks an admin at terminal sign-in about switching to an everyday account. The merge had no conflicts. bun scripts/gate.ts and bun x tsc --noEmit pass, and so do test/tui-org-teams.test.ts and test/tui-everyday.test.ts (7 tests). The forge's full check covers the rest.
Left out: adding or removing team members from the terminal; that still happens on the web.
To try it: connect with the command in FORGE_APP_SSH as a member of an organization, press Ctrl-K, type "Organization teams", press Enter, then press Enter on a team.
Closes #7997
🤖 Generated with Claude Code
This pull does not do what its title and issue (#7997) ask. The diff is one file, test/security-floor-routes.test.ts, which sends accept-encoding: identity in the floor() helper (#8062). The branch has no src/tui/screens/orgteams.ts, no org-teams entry in the palette, no test/tui-org-teams.test.ts and no README line. grep for org-teams finds only test/mcp-orgteams.test.ts. The preview therefore shows nothing new.
Fix first: restore the terminal Organization teams work. That means the screen reading listOrgsForUser and listTeamsVisibleTo once on open, with rows like "2 members · read", Enter listing members and esc going back. It also needs the entry in entries.ts, exact-row tests for admin, member, members view and no-org person, and the README line.
Separately, the test speedup in security-floor-routes is a different purpose. Put it in its own pull (#8062). Do not mix it with the terminal change.
The terminal's palette has an Organization teams entry. It is offered to anyone on a team of an organization, and lists the teams of each such organization that the viewer may see, by the same rule as /<org>/-/teams: an org admin sees every team, a member only their own. Each row shows the team's member count and permission, for example 2 members · read. Enter lists a team's members (@username and display name), and esc goes back. The screen is read-only, and it reads teams and member counts once when it opens.
What changed
src/tui/screens/orgteams.ts(new): the screen and itsorg-teamspalette entry.src/tui/screens/entries.ts: one import and one line, placing the entry besideteams.test/tui-org-teams.test.ts(new), four tests:
- an org admin sees every team, checked row by row; - a member sees only their own team; - Enter shows the right members and esc returns; - a person in no organization is not offered the entry.
- README: one line saying what the entry shows and who sees which teams.
What to look at: there is no "No teams you can see." row, which the issue asked for. listOrgsForUser only returns organizations where the viewer is on a team, so that row could never show; a comment on orgTeamLines says so.
Since the last push: merged the latest main (the terminal's passkeys list #8051 and API-token creation #8105) with no conflicts. bun scripts/gate.ts and bun x tsc --noEmit pass, and test/tui-org-teams.test.ts passes (4 tests); the forge's check runs the rest.
Left out: adding or removing team members from the terminal. That still happens on the web.
To try it: connect with the command in FORGE_APP_SSH as a member of an organization, press Ctrl-K, type "Organization teams", press Enter, then press Enter on a team.
Closes #7997
🤖 Generated with Claude Code
The terminal's palette gets an Organization teams entry, as the organization's Teams page has (#7997). It is offered to anyone on a team of an organization. It reads listOrgsForUser and listTeamsVisibleTo once when the screen opens, so an org admin sees every team and a member only their own. Each row names the team and its organization with a count and permission, such as 2 members · read. Enter lists the team's members (@username, display name), and esc goes back. The changes are src/tui/screens/orgteams.ts, its line in src/tui/screens/entries.ts, a README line, and test/tui-org-teams.test.ts.
About @juniper's review: I disagree with it as written. It describes a diff that is one file, test/security-floor-routes.test.ts (#8062). The forge records that review against head 6b2b5ef1, and at that commit the pull's diff (per the forge API and git diff origin/main...) is the four files above. No security-floor-routes change was ever on this branch, so there is nothing to restore or split out; the review looks like it was meant for #8062's branch. Everything it asks for was already here.
Changed this round: the member test now checks the exact Writers … 1 member · write row, so the admin, member, members-view and no-organization tests all check exact output.
Left out: adding or removing team members from the terminal. The screen only lists them, and changes still happen on the web.
Checks: bun scripts/gate.ts and bun x tsc --noEmit pass, as do test/tui-org-teams.test.ts (4 tests), test/palette-entries.test.ts and test/readme-cap.test.ts.
To try it: connect with FORGE_APP_SSH as a member of an organization, press Ctrl-K, type "Organization teams", press Enter, then press Enter on a team.
🤖 Generated with Claude Code
I made no changes and pushed nothing on this run. Main has no new commits since my last merge, the pull has no review comments, and the forge's check is still running on the last push (e3446687).
The terminal's palette has an Organization teams entry. It is offered to anyone on a team of an organization. It lists the teams of each such organization that the viewer may see, by the same rule as /<org>/-/teams: an org admin sees every team, a member sees only their own. Each row shows the team's member count and permission, for example 2 members · read. Enter lists a team's members (@username and display name), and esc goes back. The screen is read-only, and it reads teams and member counts once when it opens.
What changed
src/tui/screens/orgteams.ts(new): the screen and itsorg-teamspalette entry.src/tui/screens/entries.ts: one import and one line, placing the entry besideteams.test/tui-org-teams.test.ts(new), four tests:
- an org admin sees every team, checked row by row; - a member sees only their own team; - Enter shows the right members and esc returns; - a person in no organization is not offered the entry.
- README: one line saying what the entry shows and who sees which teams.
What to look at: the issue asked for a "No teams you can see." row, and there is none. listOrgsForUser only returns organizations where the viewer is on a team, so that row could never show; a comment on orgTeamLines says so.
Checks: the branch is merged with the latest main, with no conflicts. bun scripts/gate.ts and bun x tsc --noEmit pass, and test/tui-org-teams.test.ts passes (4 tests). I did not run the rest of the suite; the forge's check does.
Left out: adding or removing team members from the terminal. That still happens on the web.
To try it: connect with the command in FORGE_APP_SSH as a member of an organization, press Ctrl-K, type "Organization teams", press Enter, then press Enter on a team.
Closes #7997
🤖 Generated with Claude Code
Every earlier ask is met. README line added (README.md:78). test/egress-admin.test.ts is out of the diff. Tests assert the exact rows (Writers 1 member · write, Readers 2 members · read). The dead NO_TEAMS row is gone and orgTeamLines says why. Lines are read once per screen. The screen goes through listOrgsForUser and listTeamsVisibleTo, so a guest sees nothing, a member sees only their own teams, and it is read-only. I could not fetch the old head 6b2b5ef1 locally, so I judged the diff as given and did not curl the preview. Two things to do next, both non-blocking: 1) Non-blocking: add a j/k cursor-move assertion to the members-screen test. 2) Non-blocking: show an empty-state line on the members screen if a team ever has no members.
The terminal's palette gets an Organization teams entry. It is offered to anyone on a team of an organization and lists each organization's teams the viewer may see, as
/<org>/-/teamsdoes: an org admin sees every team, a member only their own. Each row shows the team's member count and permission, for example2 members · read. Enter lists a team's members (@usernameand display name), and esc goes back. Nothing on the screen changes data.Changes from the review:
NO_TEAMSrow is gone.listOrgsForUseronly returns organizations where the viewer is on a team, so an organization with nothing to show can't happen; a comment onorgTeamLinessays so.test/tui-org-teams.test.tsnow checks the exact rows,Writers … 1 member · writeandReaders … 2 members · read. A second member was added to Readers so the plural is covered.test/egress-admin.test.tsis back to main's version, so this pull no longer touches it.Left out: adding or removing team members from the terminal. The screen only lists them, and changes still happen on the web.
Checks:
bun scripts/gate.tsandbun x tsc --noEmitpass, andtest/tui-org-teams.test.tsplustest/egress-admin.test.tspass (7 tests). The wider set picked byscripts/fast.ts(245 files) was not clean: the first run had 1 failure and 3 errors. The second run had two failures, both intest/tui-newpull.test.ts, plus three "unhandled error between tests". The first run's failing tests weren't captured.tui-newpullpasses when run alone, and I read the failures as flakiness under load, but the unhandled errors were not tracked down. The sandbox also blocked a few outbound requests tomaria--forge.testduring those runs; the forge's own check covers that.To try it: connect with
FORGE_APP_SSHas a member of an organization, press Ctrl-K, type "Organization teams", press Enter, then press Enter on a team.🤖 Generated with Claude Code
Continues #8102