Sharing and viewers

Two things decide what a person can do in Bellwether: their role, which travels with their login, and how they reach the book they are looking at. On your home book your role applies in full. On a book you run beside it (a membership, see multiple books) you act with the membership's role, never above your own. On a book that is only shared with you, you can read and ask, never change anything, whatever your role.

Roles

On your own book, controls your role cannot use render greyed with an "Owner/operator only" hint, and the server refuses the call regardless. Under a membership the effective role is the lesser of the two: an owner login with an operator membership is an operator on that book, and a viewer login with any membership still writes nothing. Admin rights never come from a membership.

Inviting someone, sharing your book

Both live on one page now, the People page. The house owner has it at Admin › People and an operator of their own book has it at Settings › People. A search for "people", "invite" or "share" opens the right one (owner or operator, on a book you run). Its Add someone panel takes an email and decides for you. Someone who already signs in gets Read only or Operator on your book straight away. Someone new gets an invite (the house owner only) into a book of their own by default, or, when you choose one of your books, read only on it plus their own book, or a login on your book with a role. One sentence under the fields says which before you press the button. The People and access article walks through it, including the setup link that stays under a pending person's row with Copy link and Send a fresh link.

What has not changed: you confirm with an authenticator code (one from the last 30 minutes counts; resending a link and disabling a login want one from the last 5); a setup link works once and expires after 30 minutes; the person chooses their own password and enrols their own authenticator, nobody is ever handed a preset one; when the server sends mail the link is emailed and otherwise it is only saved, and either way the owner can read it on the person's row and in the Mail log on Admin › People.

Once you have given someone read only on your book, it appears in their book switcher under Shared with you (read only), with a lock and your initial. Picking it reloads the console so nothing cached from their own book lingers, shows a persistent bar under the top bar saying they are viewing your book read-only, with a Back to my book link, and shows them what you see: positions, sessions, research, reports, activity. Notes they leave through the Report button land in your feedback log with their name and a read-only tag. The house owner can look at any book the same way, and is read only there too.

An Operator role on your book for someone who has their own book (a membership: they run yours beside theirs) is the other option on the same form; it is capped by their login's own role, and Admin rights never come from it.

What a viewer can and cannot do

"Viewer" covers two people who end up with a hands-off view: a login you invited into your book with the Viewer role, and anyone looking at your book through a share (a visitor; this includes the house owner, whose own role does not carry over). The server decides both from the session, never from the page, and answers 403 to anything outside the list below. The console handles the two differently on purpose: a Viewer-role login sees controls greyed with a hint, while a visitor never meets a control that would fail: every button, slider, switch and form that writes is hidden for them, edit-only screens turn into read-only summaries, and Lab and Settings drop out of the rail. Opened by address, Lab shows one line, "You are viewing ‹book› read-only", and a Back to my book button. Settings keeps the two tabs that are the visitor's own, Account and Display (their password, authenticator, sessions and how the console reads). The book's alerts, broker and book settings are its owner's to change, so those tabs are not offered.

Two differences worth remembering: a Viewer-role login cannot send feedback or ask Consult at all, while a visitor usually can do both; and a visitor's whole console carries the read-only bar, whereas a Viewer-role login sees ordinary-looking settings screens whose saves the server turns away. Sessions keep re-checking the login and the share about every 30 seconds, so a revoked share or a disabled login stops a screen that is already open. An API token minted on one book and pointed at another is read-only there as well.

Reviewer feedback never reaches the PM

Notes from a reviewer or a visitor go to the feedback log and the operator, never to the PM. There is no path from a Report to a guidance note, a lesson or a prompt; the operator reads it, decides, and only then changes something. The same holds for a visitor's Consult questions: they live in threads no member can post into and that never produce a card, and no role searches Consult transcripts, so a visitor's words cannot end up in a conversation that changes the book. Expert input is discussed, not ingested.

Revoking

• Remove access: on the People page (Admin › People, or Settings › People for an operator of their own book) click the person's chip for your book, Read only or Operator (or open the row's ⋯ menu), and choose Remove access. No code needed; it takes effect on their next request, and a live screen they already have open stops updating within about 30 seconds. The chip through which a book's owner reaches their own second book cannot be removed here, and neither can your own access.
• Disable a login: open the row's ⋯ menu and choose Disable login (house owner; a code from the last 5 minutes). Their sessions and remembered browsers end immediately and any open live screen closes within about 30 seconds; nothing is deleted, and you can enable them again later.