[lavaman131]

Count and list teammates' shared machines with the person's own, and let one be their default

Summary

A machine a teammate shares is now treated like one of the person's own wherever machines are counted or listed. The sidebar's Machines count includes it (one own machine and one shared machine, both connected, read 2/2). The Machines menu in the sidebar, the machine button's menu beside Build plan, and the Machines page list it plainly under Local or Cloud, sorted with the person's own (newest paired first, whoever owns the machine), with no "Shared by " group and no separate "Shared with you" table. A person can make an eligible shared machine their default (their favorite), and Default machine and Automatic prefer it for their documents where it serves the repository, falling back as before where it doesn't. Owner-only actions (rename, the Shared switch, disconnect, setup and update) stay with the owner.

What changed

Count. summarizeMachines now counts total (not paired) over the person's own machines and the teammates' shared ones. The entry reads 2/2, and its accessible name is Machines, N connected, Machines, X of Y connected or Machines, none of Y connected. The Machines page's "N machine(s)" counts every row of its one table.

Order. Every list of machines is in one order, newest paired first, then by id: the order the server already lists the person's own machines in (created_at DESC, id). A teammate's machine row, and a machine in a document's menu, now carry createdAt (a field of the stored machine, not a GitHub call), and newestFirst() sorts the person's own and teammates' machines together with it. allMachines() (the sidebar menu, the Machines table and the count) and machineRows() (the machine button's menu) use it, so a teammate's machine paired after one of the person's own is above it in Local or Cloud, and one paired before is below it, on all three surfaces. Nothing groups by owner.

Machine button menu. machineRows() returns one list: Local, then Cloud, each in that order, offline ones disabled. The per-owner groups are gone. A teammate's login appears after the name, in quiet ink, only where another machine in the list has the same name.

Sidebar Machines menu. It lists teammates' machines beside the person's own, as radio items that set their default. The entry opens the menu, not a link to /machines, when the person has no machine of their own but can use a shared one.

Machines page. The "Shared with you" table is removed. A teammate's machine is a row of the one table, in the same columns: name, owner (its owner's login), host and agent (a dash, as the API gives none), version, Shared, last seen, actions. Its Shared switch is on and disabled, it has no actions menu, no Update badge, and no rename, disconnect or setup; its star, the person's own default, works. On a phone the same rows are in the one list and its view offers the star alone.

Favorite. POST /api/connector/machines/:id/favorite now accepts a machine a teammate shares when it is listed to the person: shared, not revoked, its owner and the person able to push to a repository (the Machines page's own listedTo(), over the same reach cache and held GitHub lists; no new GitHub call). Anything else, and anyone clearing a favorite they don't have, is a 404. A person has one favorite across their own and teammates' machines. GET /api/connector/machines gives a teammate's row favorite (the viewer's own flag, never its owner's). /label, /shared and /revoke still answer a non-owner 404.

Clearing. The owner stopping sharing a machine clears teammates' favorites of it (not their own); revoking it clears everyone's. Storage does both: MachineStore.favor() accepts a shared machine of another person, share(false) deletes the others' favorites in the same transaction on PostgreSQL, and the memory adapter's revoke now clears every person's favorite (it cleared only the owner's). No schema change.

Favorite and unshare. The favorite route stored a favorite, then published it to the in-memory choices; unsharing stored its clearing, then published that. An unshare that landed between a favorite's two steps cleared storage, then the favorite's publication put it back in memory, so it reappeared on the next share and Automatic, Default machine and mayTake() preferred it with nothing stored. A favorite change, stopping sharing a machine, and revoking it (the owner's and the machine's own unpair) now run one at a time per machine (changingFavorites()), each storing and then publishing with nothing between, so memory never keeps a favorite storage has cleared. No new GitHub call.

Rebuild. A pressed rebuild tried the connection of the build before it first, so a shared machine made the person's favorite after that build was ignored. It now tries the person's favorite shared machine first (favoriteShared(), through the same takers()/mayTake() checks: connected, serving the repository, its owner able to push, not busy), then the original connection and the person's others as before; a machine chosen for the document still wins (no favorite applies while one is chosen), and rebuilds Chopin starts by itself (LIVE_BUILD) still stay on their builder's own machines.

Preference. For a document with no machine chosen, a teammate's shared machine the person favors takes their Build, Retry, Run, investigations and manual rebuild first while it is connected, serves the repository and its owner can push to it (requested(), allows(), mayTake(); the same checks as a chosen shared machine), and the document's machine state names it as what Automatic uses. A machine chosen for the document comes first. Default machine runs the creator's Planner on it before their own machines (favoritePlannerMachine(), and reachShared() now checks it even when the creator has a machine of their own); it moves there, and back, when the creator's favorite changes. Offline, unshared, or its owner no longer able to push: they go where they would without it. Rebuilds and prototypes Chopin starts by itself (LIVE_BUILD, LIVE_SPIKES) still run only on their builder's own machines.

Docs. docs/chopin-cli.md, docs/implementation-lifecycle.md, docs/local-launcher.md, docs/storage.md, docs/hosted-agent.md, docs/agent-connection.md, AGENTS.md and apps/web/DESIGN.md say so.

Tests

• Storage contract (machine-contract.ts, memory and PostgreSQL): a favorite may be a teammate's shared machine, refused while it is not shared or someone else's; one favorite per person across both; unsharing clears teammates' favorites and not the owner's; revoking clears everyone's; owner-only actions stay with the owner.
• Server, planner-dispatch.test.ts: favoriting allowed when eligible, refused when not shared, whose owner can't push, or that the person can't use, and for an unknown id; one per person; the viewer's flag on the listing and none for the owner; cleared on unshare and on revoke; rename, share and revoke still refused; Automatic's machine in the document's state; Default machine runs the Planner on the favorite ahead of the creator's own machine, falls back offline, when unshared and when its owner can no longer push, and moves it when the favorite changes.
• Server, tasks/routes.test.ts: Build on Automatic goes to the favorite shared machine and runs there for the person; the person's choice for the document beats it; it falls back to their own machine offline, unshared, and where its owner can't push; it counts as the local agent; a pressed rebuild goes there and an automatic one never does.
• Mutation checks: four one-line breaks (the local-agent check, reachShared() skipping the favorite, no clearing in memory on unshare, mayTake() ignoring the favorite) are each caught.
• Web: the count, label and totals (machine-summary.test.ts), the menu rows and same-name owner (machine-choice.test.ts), the one table with teammates' rows, the disabled checked switch, no actions, the star and the count (machine-list.test.ts). The ordering cases replace the ones that locked in own-first: a newer shared machine above an older own one and an older one below a newer own one, in Local and Cloud, whatever order the lists arrive in, and one order for machines paired at the same moment (allMachines(), machineRows() and the table).
• Server, planner-dispatch.test.ts: a teammate's row, and a machine of the document's menu, carry the machine's createdAt, the stored one; the teammate's row has no other owner-only field.
• Server, tasks/routes.test.ts: forced interleavings of the favorite request, held after it stored the favorite and before it publishes it, with the owner stopping sharing the machine (then sharing it again), revoking it, and the machine unpairing itself: afterwards the person has no favorite in storage or memory, nor on the reshare. A rebuild goes to the shared machine the person made their favorite after the first build ran on their own; it stays where the first build ran while that favorite is offline, and a machine chosen for the document still takes it.
• Browser (e2e/planner-picker.e2e.ts, HARNESS=remote): the sidebar menu, the Machines table and the document's menu list six machines, three of them teammates', newest paired first, interleaved in Local and Cloud; and the one Machines table with the count and a disabled switch on a teammate's row, on a phone too; owner-only routes refused; the Build button menu and the phone sheet with Cloud rather than "Shared by"; the sidebar's 2/2, its menu listing and choosing a shared machine as the default, the Machines page, Automatic's "Runs on", offline, and the default let go on unsharing; and a person with no machine of their own opening the menu, with the owner named only beside a same-named machine. e2e/machine-choice.e2e.ts: the count label.

Screenshots

All under /tmp/chopin-shots-shared-plain/ (taken from the Playwright run, viewed and reviewed):

• machines-count-shared.png: the sidebar entry reading 2/2
• machines-menu-shared.png: the Machines menu with Local (Laptop) and Cloud (Build box), no owner group
• machines-menu-same-name.png: two machines named Desk, the teammate's with its owner's login in quiet ink
• machine-button-menu-shared.png: the Build button's menu, Local and Cloud, the shared machine in use
• shared-machine-menu.png: the same for a person whose only machine is a teammate's
• machines-table-shared-and-own.png: the Machines page, "2 machines", Local and Cloud, the shared row's switch on and disabled, its star set
• machines-menu-order.png, machines-table-order.png and machine-button-menu-order.png: six machines, three of them teammates', 6/6, in the sidebar menu, the Machines table and the document's menu; Local is Desk, Studio (a teammate's), Laptop and Cloud is Edge (a teammate's), Rack, Build box (a teammate's), so a teammate's machine is above or below the person's own by when it was paired
• machines-table-shared.png and machines-shared-no-checkout.png: the Machines page for a person with only a shared machine
• machines-shared-phone.png: a shared machine's view on a phone, the star alone
• shared-machine-phone-sheet.png: the phone's machine sheet

Risks

• A person can now make a machine they do not own their default, so their Automatic Build, Retry, Run and investigations run there, as its owner, with the owner's GitHub account, as a chosen shared machine's do. Sharing is already the owner's consent to that, and the pairing card and Shared switch say so; the copy now says "or make it their default".
• A pressed rebuild now follows the person's shared favorite even after a first build ran elsewhere, as its owner; the person's own favorite among their own machines still does not move a rebuild off the machine of the build before it.
• A revocation that ends a machine because its owner lost admission (not the Machines page, the machine's own unpair, or an administrator) still leaves teammates' in-memory favorites of it until a restart: the machine is revoked and never connects again.
• A favorite request that reaches storage after the machine was unshared still ends as a server error, as before, not a 404.
• A favorite on a machine whose owner can no longer push is passed over, not cleared, until the owner stops sharing or disconnects it: the machine leaves the person's list and nothing in the UI shows the stale default.
• The Machines page keeps its "Add your first machine" banner for a person whose only machines are a teammate's.
• Host and Agent are dashes on a teammate's row: the API gives a teammate nothing of the machine's host, system or agent. The repositories a machine serves, still in the API, are no longer shown on the page.
• The Machines table is still named "Your machines" for assistive technology; it now holds teammates' machines too.

Verification

Each command ran on the source it names; the branch is three signed commits on origin/main 9fb72d4 (#789): the favorite as a teammate's machine, the count and the lists, and the repair of three review findings (the order machines are listed in, a favorite surviving an unshare, a rebuild ignoring a new shared favorite). The trailers below are the repair commit's, plus the earlier commits' checks that still hold.

Assistant-model: Claude Sonnet 5.5
Assistant-workflow: goal (run ea3bb0ce-3067-42c3-949c-86a4fa4b7d59)
Assistant-duration: 53m converged, estimated 120m (the repair commit; the count and lists commit was 39m converged, estimated 90m)
Assistant-verification: bun test passed: 7269 pass, 17 skip, 0 fail across the repository on the final source (7261 on the previous commit plus 8 new cases), with a disposable PostgreSQL 17 at TEST_DATABASE_URL on port 5433, run with GIT_CONFIG_GLOBAL=/dev/null because the global commit signing breaks one test's scratch repository
Assistant-verification: bun test apps/server/src/storage/postgres passed: 128 pass, 0 fail against the same PostgreSQL 17 on port 5433, run in place of bun run test:postgres, whose fixed port 5432 is another project's database on the machine this was written on; the three favorite contract cases pass on memory and PostgreSQL
Assistant-verification: the new and changed cases fail on the previous commit's server and web code and pass after: with the five production files (experiments/routes.ts, tasks/builds.ts, tasks/routes.ts, machine-summary.ts, machine-choice.ts) restored to 9216a30 and these tests kept, tasks/routes.test.ts, planner-dispatch.test.ts, machine-summary.test.ts, machine-choice.test.ts and machine-list.test.ts gave 11 fail and 225 pass: the three favorite-versus-owner interleavings (unshare then reshare, revoke, unpair), the rebuild on a favorite made after the first build, the teammate's and the menu's createdAt, and the four ordering cases (the sidebar and table list, the menu rows, a tie, the table)
Assistant-verification: five one-line mutation checks were each caught by exactly the case for the code it breaks: the machine's own unpair, the owner's revoke and the unshare each taken back outside the per-machine order failed only their own interleaving case, the favorite route taken outside it failed all three, and queueRebuild ignoring the favorite failed the rebuild case alone; the earlier four (the local-agent check dropping the favorite, reachShared() skipping it, the unshare clearing of teammates' favorites removed, and mayTake() ignoring it) are still each caught
Assistant-verification: bun run fix, bun run types and bun run ci passed on the final tree: fix changed nothing, 14 of 14 workspaces and e2e typed, 71 lint warnings as before, tokens, design contract, design record and design check
Assistant-verification: GIT_CONFIG_GLOBAL=/dev/null CHOPIN_SHOTS=/tmp/chopin-shots-shared-plain bun run e2e planner-picker machines machine-choice connector passed on the final tree with a freshly built client: 63 passed, 0 failed, on four disposable PostgreSQL 17 databases, including the new interleaved-order case; an earlier run of the same specs gave 62 passed and 1 failed, machine-choice.e2e.ts:682 (the sidebar machine menu closes on browser history navigation: the menu does not open on the second click), which also fails on the unchanged previous commit in 4 of 82 repeats against 7 of 58 on this tree, so it is an intermittent failure of the test, its cause not found
Assistant-verification: screenshots viewed after the retake: the three *-order.png shots (six machines, three of them teammates', listed Desk, Studio, Laptop under Local and Edge, Rack, Build box under Cloud, 6/6, interleaved by when each was paired), machines-count-shared.png (2/2), machines-menu-shared.png, machine-button-menu-shared.png, machines-table-shared-and-own.png and machines-menu-same-name.png, from Playwright runs of the same web code
Assistant-verification: not run: the phone screenshots' review after the retake, the Docker image build (no dependency, workspace or Docker change), bun run design:behavior and the full bun run e2e suite (only the four specs that touch machines), and GitHub's checks on a pushed head (no branch was pushed and no PR was opened)
User-preference: Shared machines are listed and counted plainly with the person's own, not grouped by owner
Co-authored-by: Alex Lavaee lavaman131@github.com