stack/agents/morgana/work/queue-193/DESIGN.md

Row 193 design: many humans per business, human roles, private and shared threads

Morgana (Opus 5.5), 2026-10-20. Revision 5: sage-1373 item 1 (mos-1023 item 2), the user sentence names every record the owner sees. Revision 4: duckworth-0011 B3 and N5. Revision 3: duckworth-0008 B1, B2 and N1-N4, sage-1368. Revision 2: sage-1354 (5.7 private from the owner, 193b split) and gizmoduck-0018 (coverage and the R4 predicate in FED r4.1). Gitea #1691, queue row 193, brief docs/plans/2026-10-20_human-users.md (blob f7472d1e47). Reviewer Duckworth, gate owner Sage. Base: refactor at 53bb59462.

Read for this design: COMMON.md (53bb59462), the brief, Gizmoduck's federation design r4.4 (b67bc6de9 on gizmoduck/federation-design, cited as FED; r3.1 a2840a6be was read first), Duckworth's federation reviews (b402197ff, 03a663cd7, 45cbe5896 on duckworth/reviews), Sage's Q175 SSO design (agents/sage/work/q175-sso/DESIGN.md), the row 192 and row 196 briefs, Darkwing's row 190 packet (uncommitted, sha256 5493c9df3ec0...), and the bus, business, cli and webui code at the lines cited. Messages: morgana-0001 to 0003, sage-1338, gizmoduck-0009, gander-0002 and gander-0005.

1. Summary

• Three human roles: owner, collaborator, viewer. The owner is the business file's one human, as today. Collaborators and viewers are access.json users, the same store federation uses (FED 3.5). Their role is the level of a grant, so a role is per project and instance, not per person.
• Every human principal is minted by one bus verifier, owned by row 196 (Gander). Row 193 states what it needs from that verifier (section 6) and adds no second mechanism.
• Threads stay private to their owner by default. A thread owner may share a thread, read-only, with a named user, with the owner, or with everyone granted on it. Shares live in a new append-only bus table, thread_shares. This is a deviation from brief point 4, agreed by Sage (sage-1338), for Duckworth to rule on (section 5.1).
• A share never widens a grant. It counts only while the reader's live grant covers the thread's project and instance, and while the thread's owner still has coverage. Revocation, expiry and unsharing take effect on the next request.
• Existing businesses keep working unchanged: every existing thread is already owned by the business human, and an instance without access.json has exactly one human, the owner.
• The build splits so the part without a schema change can land first. thread_shares needs schema 3j and a --migrate window with Jason.

2. What exists today (measured at 53bb59462)

• One human per business (packages/business/src/business.mjs:160). bindHuman refuses any other name (packages/bus/src/broker.mjs:532-538).
• The owner's CLI proof is path-bound (#225): verifyHuman checks uid, start time, nonce (MOSAIC_BUS_CLI_NONCE), argv[1] equal to the tree's human-cli.mjs, then walks parents and refuses agent markers, launch records and agent binaries (packages/bus/src/human.mjs:64-96). authenticateHuman binds the proof to businesses[business].human (packages/bus/src/runtime.mjs:175-182).
• Threads: threads(seq,id,at,business,project,instance,owner,name), append-only (packages/bus/schema.sql:247, triggers at :310-312). #owner(s) returns tester or s.human (broker.mjs:364-366). #thread refuses a non-owner with thread-not-owned (:357-362).
• Thread verbs are gated if (!s.tester) this.#human(s): project.list (:2318), thread.create (:2325), thread.list (:2351, owner filter), thread.open (:2365), thread.send (:2374, writes human.input for the human only), thread.messages (:2401).
• Board reads are business-wide and human or reader only: inbox, agents, tasks, trail (:2143-2167), decisions (:2174), credentials (:2195), messages (:2217, to_role='human'), replies (:2422). trail and replies return any message in the business by id (:2679-2700, :2422-2432).
• The Console reads threads by polling the same verbs (packages/webui/src/chat.mjs:22-26). It has no stream, so a refusal on the next poll ends access.
• The launcher restarts a thread with pending messages as the business human (packages/cli/src/launcher.mjs:533-542).

3. The human model (brief point 1)

3.1 Who the humans are

Human	Where it is declared	How many	Identity
owner	business file human (unchanged)	exactly one per business	the business human's name
user (collaborator or viewer)	access.json users[] with home: "local" (or a peer id under federation)	any number	user:<id>
tester	not a human; row 177 test principal	one	tester

The owner stays outside access.json (FED 9 Q2). A business has no second owner and no admin level. Adding one is out of scope; section 9 lists it as a follow-up for Jason.

3.2 How a sign-in or a call becomes exactly one human

Entry	Becomes	Checked by
Console SSO session whose (provider, sub) is in console.sso.providers[].subjects (row 192)	the owner	the Console after OIDC checks, then the bus verifier (row 196)
Console SSO session whose (provider, sub) is a users[].subjects entry in access.json with a live grant	that one user	same
Console SSO session matching neither	nobody: refused	the Console, and the bus refuses any later claim
CLI call through human-cli.mjs that passes the human proof	the owner	the bus (verifyHuman)
Any other process, including an agent	nobody	the bus

Why each is exactly one:

• The R1 loader refuses a (provider, sub) pair that appears twice in access.json or also in console.sso.subjects (FED 3.5). So one subject maps to at most one human.
• A user id can't be human, tester or any business's human (FED 3.5). So a user can't be named as the owner.
• A terminal maps only to the owner. The only identity the bus can verify for a local process is the instance's OS user, and that is the owner's. A user has no CLI path in row 193. This follows Mos's B1 rule (mos-0985): the principal comes from what the bus verifies, never the process's own claim.
• The bus never reads a user name from a request body as identity. The verifier returns the principal (section 6).

4. Human roles (brief point 2)

4.1 The three roles

• owner: everything the business human does today. Only the owner restructures the organization (business file writer, project and role changes) and only the owner manages users and grants.
• collaborator: FED 3.5's level, unchanged. Creates threads in granted projects on granted instances, sends into and opens its own threads, and in row 193 also shares its own threads.
• viewer: new. Reads threads shared with it, within its grant. It creates, opens and sends nothing, so it never drives an instance. FED 3.5 notes that a collaborator's message drives the instance with the owner's role authority (F10). A viewer has none of that.

The word "collaborator" stays, so FED's tests and help text need no rename. The brief's example "member" is this level.

A role is the level on a grant, and a grant is per business, project set and instance set. A user may hold a collaborator grant on one project and a viewer grant on another. Every check asks "does a live grant of a level that allows this verb cover this project and instance". A user has no single role.

4.2 R1 widening

FED R1 refuses any level but collaborator, because the 10-27 slice ships only that (FED 9 Q2). Row 193 widens R1's level check to collaborator or viewer, with its own test that each is accepted and anything else refuses. Nothing else in the access file changes. If R1 has not landed when row 193 builds, this one-line widening goes into the row 193a candidate chained on R1's candidate (Q177).

4.3 Bus verbs per role

Every verb not in a user's column fails access-refused before its own checks, as FED 3.5 requires for collaborators. That covers every owner verb, every board read, message.*, decision.*, project files, spec.read, assistant.stop, launch.*, name.set, usage.* and access.reload.

Verb	owner	collaborator	viewer
project.list	all	projects covered by any live grant	projects covered by any live grant
thread.create	yes	collaborator grant covers project and instance	refused
thread.list	own threads	own threads still covered	own threads still covered (from an earlier collaborator grant)
thread.list {shared: true} (new)	threads shared with the owner	threads shared with me and readable (5.4)	same
thread.open	own	own, collaborator grant still covers	refused
thread.send	own	own, collaborator grant still covers, no human.input	refused
thread.messages	own, or shared with the owner	own (any level still covering), or shared and readable	same as collaborator
thread.share, thread.unshare (new)	own threads	own threads, collaborator grant still covers	refused
thread.shares (new)	own threads	own threads	refused
names	all	instances covered by any live grant	instances covered by any live grant
every other verb	as today	refused	refused

Notes:

• thread.list keeps its response shape exactly. Shared threads come only from thread.list {shared: true}, whose rows add owner. The Console and existing tests read the plain list unchanged.
• A viewer can still read its own threads when a collaborator grant is lowered to viewer, but can't send or open them. This is the downgrade path.
• The tester keeps its row 177 verbs. It can't share or be shared with: thread.share, thread.unshare and thread.shares fail tester-refused, and a share target is never tester. Agent testers (Q173) test sharing through the bus suites, not the live 7333 listener.
• reader sessions (Console read caps, broker.mjs:1303) are the owner's board view and stay owner-only. A user never gets a reader session.

4.4 Console per role

• owner: as today, plus a share control on each own thread and a "Shared with me" list.
• collaborator: the chat view only, for granted projects (FED R6's granted-user sign-in), plus share controls on its own threads and "Shared with me". No board.
• viewer: "Shared with me" and its own old threads, read-only. No composer, no open, no share control.
• The Console hides controls a role can't use, but the bus check is authoritative. A Console bug can't widen a grant (FED 3.6). Each role gets a webui test with the UI check removed (mutant) that the bus still refuses.

4.5 Who manages humans and roles

Only the owner, through mosaic access (FED R5), which checks the human proof and refuses tester and agent callers. Row 193 needs from R5:

• mosaic access user add <id> --home local --subject <provider>:<sub> and user remove <id>;
• --level viewer on grant;
• the receipt line in <dataRoot>/state/access-log.jsonl and the access.reload call, as FED R5 has.

If R5 has no user verbs when row 193 builds, row 193c adds them on R5's candidate. The Console gets no user or grant writes in row 193: a write from the Console would need a new owner verb that writes access.json from the bus, and access.json is a config file only the owner's CLI writes. A read-only users page for the owner is a follow-up (section 9).

The owner keeps every restructuring power (TARGET Case 1). Users can't touch the business file, projects, roles or access.json.

5. Private and shared threads (brief point 3)

5.1 Deviation from brief point 4, agreed by Sage (sage-1338)

Brief point 4 says access.json is the one store. Users, roles and grants live there. Per-thread shares do not, for three reasons (morgana-0002):

• F1. Thread ids are bus-generated UUIDs. A hand-typed share with a typo would fail the loader, and the loader refuses the whole file on any failure, which revokes every user.
• F2. Only the owner writes access.json. A collaborator could never share its own thread.
• F3. Threads are append-only bus rows, and a share is a runtime act by a principal that wants a trail.

So shares go in an append-only bus table, gated by the grant. Sage agreed (sage-1338). Gizmoduck had no objection (gizmoduck-0009) and recorded it as FED 9 Q2. Duckworth rules on it in this review.

5.2 Schema 3j

CREATE TABLE thread_shares (
  seq INTEGER PRIMARY KEY AUTOINCREMENT,
  at TEXT NOT NULL,
  business TEXT NOT NULL,
  thread TEXT NOT NULL REFERENCES threads(id),
  op TEXT NOT NULL CHECK (op IN ('share','unshare')),
  target TEXT NOT NULL,
  by TEXT NOT NULL
) STRICT;
CREATE INDEX thread_shares_thread ON thread_shares (thread, target, seq);
-- no_update, no_delete and no_replace triggers, as thread_opens has (schema.sql:319-321).

• target is an owner string: user:<id>, the business human's name, or *. A share whose target is a name that is no longer the business's human (after a rename) is void: rule 1 in 5.4 compares against the current owner string, so it matches nobody (Duckworth N4).
• by is the sharer's owner string, which is always the thread's owner.
• A share's state is its latest row per (thread, target) (Duckworth N12, REVIEW-r3.md:74-76). Shares are not assumed to only grow.
• No existing row changes. Existing threads are already owned by the business human (#owner at broker.mjs:364-366), so they are the owner's and private. The brief's "all become the current human's" is already true.

The migration 3i-3j.sql creates the table, index and triggers. thread_shares joins every table list that holds timed append-only tables: timedTables in store.mjs (:60-74), the broker's clock list (broker.mjs:223-235), the restore guard's counted tables (row 181) and COUNTED in scripts/stack-release.sh:315. The schema digest for 3j is pinned as the other versions are.

5.3 Verbs

• thread.share {thread, to}: the caller must own the thread (thread-not-owned). For a user, a collaborator grant must still cover the thread. to is user:<id>, the business human's name or *. A user:<id> target must have a live grant, of any level, covering the thread's project and instance, else share-not-covered. Sharing with yourself fails invalid-request. A share that is already in force fails share-exists. Writes one share row.
• thread.unshare {thread, to}: the caller must own the thread. The share must be in force, else share-not-found. Writes one unshare row. Unsharing the owner's or * shares works the same way.
• thread.shares {thread}: the caller must own the thread. Returns the shares in force, latest row each.
• Both writes go through refuse() on failure, so each refusal records action.refused with by set (FED 3.6 item 6).

5.4 The read check, one function

#readable(s, t) decides whether a session may read thread t it doesn't own. True only when all hold:

1. a share for t is in force whose target is the caller's owner string, or *;
2. the caller is the owner, or the caller has a live grant of any level covering t.project and t.instance;
3. if t.owner is a user, that user still has a live grant covering t (a revoked owner hides the thread, sage-1338);
4. t.owner is not tester.

#thread(s, id) keeps its owner check for thread.open, thread.send, thread.share, thread.unshare and thread.shares. A new #threadRead(s, id) admits the owner or #readable, and serves only thread.messages. A sharee fails thread-not-owned on every write verb.

5.5 Every read path and its filter

Read path	Today	After row 193
thread.list	owner=?	unchanged for the owner; for users also each row's thread still covered
thread.list {shared: true}	none	rows where #readable holds
thread.messages	#thread	#threadRead
thread.open, thread.send	#thread	#thread, plus a collaborator grant for users
project.list, names	business-wide	per FED 3.5 for users, unchanged for the owner
trail, replies	human, reader or tester; any message by id	users refused (access-refused); for the others, messages in other users' unshared threads hidden (5.7)
messages, inbox, agents, tasks, decisions, credentials	human or reader	users refused (access-refused); owner unchanged. A user-thread run can't send to the human (user-thread-human, FED 3.6), so messages holds none of a user's thread
message.receive by a run	its own thread (:1933)	unchanged: runs read their own thread, never a share
threadsState (launcher)	all threads	adds revoked per 5.6

5.6 Revocation, expiry and unsharing

Gizmoduck asked that a grant loss end access to threads shared with that user (gizmoduck-0009 point 2).

• A sharee holds no claim and no run. Its access is only reads, and every read runs #readable against the access state the broker already refreshes on each request (mtime, size, inode), on its 30 s timer, and on access.reload (FED 3.7). So a removed, expired or invalid grant ends share reads on the next request, with nothing to tear down. The Console polls, so a revoked sharee's next poll fails.
• An unshare row ends access on the next request in the same way.
• A user who loses coverage of their own thread also loses its shares: rule 3 in 5.4.

The downgrade case. With viewer, "no live grant covers" would be wrong for runs: a viewer grant covers the thread but must not let a run continue. FED puts this in R4: revoked, claim end and the launch check call covers with level collaborator, so a downgrade to viewer ends the run within one launcher tick. FED r4.4 (b67bc6de9, mos-1020) chains R4 after row 193's viewer level (193a) and keeps the level-loss test and its mutant in R4. Row 193 carries neither (Duckworth N3), so the mutant has one owner.

5.7 What "private" means, stated plainly

Sage ruled (sage-1354): a user's thread is private from the owner on the bus too. Jason's words are "private agent sessions per user", and in Case 2 the owner of Melanie's hub is not the user whose thread it is. Duckworth's B1 asked where the line sits, since a user-thread run acts with the owner's role authority (F10). I took Duckworth's option (a): the user's messages are private, and the run's governance is not. The run spends the owner's authority, so its decisions, task writes and claims are the owner's to see and answer. Filtering them too (option b) would need a thread link on decisions, more schema, and would hide from the owner what is done in the owner's name.

Every read an owner or reader session has, and its side of the line:

Read	Shows	Side
thread.list, thread.messages, thread.open	own threads only, plus shares to the owner from 193b2	private: other users' threads never appear
trail	events, messages, decisions and deliveries by subject	messages filtered (below); decision rows and their events stay visible
replies	messages replying to an id	filtered (below)
messages, message.receive, message.read	messages to_role='human' (broker.mjs:1931-1936, :1953)	private by construction: a user-thread run can't send to the human (user-thread-human, FED 3.6 item 7)
inbox	open decisions routed to the human	governance, visible
decisions {list: roles | recent}	decision rows with question, options and recommendation	governance, visible
agents	role claims and each held role's state	governance, visible
tasks, state	tracker tasks and launch state	governance, visible
credentials, usage	credential state, usage records	governance, visible; neither holds message text
project.files, project.file	project files, including records a run writes with record.write (broker.mjs:1395-1407, :1441-1450)	governance, visible
project.list, names	projects and instance names	business-wide for the owner, visible

So a decision a user-thread run raises shows in the owner's inbox or decisions, with the free text the run wrote. Its role claims show in agents, its task writes in tasks, and a record it writes in project.file. Any of these can quote the user, and 5.7 doesn't call them private. The users' help text (R5) and the Console's share and thread pages say so in one sentence, which FED R6 reuses (mos-1023 item 2, duckworth-0012 N21):

The business owner sees your thread's agent's decisions, inbox entries, claims, tasks and project files, but not your messages.

The gated-raise route. A user-thread run's uncited gated raise or hard wait routes to the human (broker.mjs:1677-1680). FED r4.5 (acd5f1f42, B9) settled this with no guard: the tester guard at :1683 (tester-thread-human) is not copied, and the decision reaches the owner's inbox and no other (sage-1368, mos-1021, mos-1022). FED R3 tests it. Row 193 adds nothing here.

The message filter. A message is hidden from a session when it is in a thread (message_threads) whose owner is a user:<id> other than the caller, and #readable(s, t) is false. Threads owned by the business human or by tester are not affected, so row 177's behaviour is unchanged.

• trail: drops hidden messages, their deliveries rows, and events rows whose subject is a hidden message id. A subject that is itself a hidden message returns message-not-found, as an unknown id does, so the reply doesn't confirm the id exists.
• replies {id}: a hidden id fails message-not-found, and hidden messages are dropped from the result.
• It applies to every session that can call these verbs: the owner, reader sessions and the tester.
• It lands in 193b1, with no schema (Duckworth B2). Before 193b2 there are no shares, so #readable is false for anyone but the thread's owner and b1 hides every message in another user's thread. 193b2 adds only the share exception. So no build order can put a user thread live without the filter.

What it does not do. The owner holds the store as the instance's OS user and can read it with sqlite. That is the same-uid limit in section 6, not a bus path. An owner audit verb, explicit and logged, is a follow-up row only if Jason asks for one (sage-1354).

6. The bus human boundary (brief point 5)

Row 196 (Gander, #1694, brief docs/plans/2026-10-20_human-boundary.md at 96f243faf) owns P19 333 and the verifier. Row 193 cites it and designs no boundary of its own (sage-1338: one mechanism).

Agreed with Gander (gander-0002, morgana-0003, gander-0005):

• One bus verifier, verifyPrincipal(request, connection) -> {kind, business, id}, kind owner, user or tester. It mints one transient principal per request. It returns no role. The broker reads the level from the live grant on every request, so a grant change acts without a new principal.
• Gander recommends FED 3.6's shape for users (path-bound user-cli.mjs, direct parent the bus tree's packages/webui/src/cli.mjs serve) plus kernel peer PID binding, and weighs bus-side ID-token verification as the larger alternative.
• Correction from Gander, accepted: the tester proof doesn't run the full agent walk, because agents bind tester by design (Q173). Managed runs still fail it. The tester listener moves from TCP 7333 to a private Unix socket, with bus.tester unchanged (agreed by Sage with Gander).

What row 193 needs from row 196:

• H1. Owner on the CLI keeps today's proof. Owner in the Console is a console.sso.subjects entry.
• H2. A user principal comes only from an OIDC sign-in, through a path the bus verifies. No CLI path for users.
• H3. The user binding fails closed on no live grant, an unknown subject, a subject also in console.sso.subjects, or a missing or invalid access.json. A broken access.json never stops the owner.
• H4. Agent processes never get an owner or user principal.
• H5. Revocation ends a bound user within 30 s and at once on access.reload, from the same access state row 193's share check reads.

The same-uid limit. Within one instance, a non-agent process on the instance's uid can claim the owner, and can start its own Console copy and claim any granted user (FED 3.6). An unsandboxed same-uid agent that detaches from its ancestry can do the same. The walk doesn't stop that, and Gander's design won't claim it does (gander-0005). Several humans don't make this worse: a user principal is no stronger than the owner principal that the same process could already take. Users themselves are not on the uid. They reach the bus only through the Console, so the limit is about local processes, not other humans.

Does row 190 narrow it? Row 190 runs several instances under one uid, so no. Row 190b puts an instance (the hub) under its own Linux user (mos-0986). That narrows reach across instances: another instance's uid fails the uid check (human.mjs:67) and can't read the hub's store or access.json. It does not narrow reach within one instance. Private threads are private from other humans using the bus, not from processes running as the instance's uid.

7. Migration and rollback (brief point 6)

• No access.json: the business has exactly its owner, every verb behaves as today, and the share verbs work for the owner only (target * or none). A broken access.json revokes users and leaves the owner.
• Existing threads: already owned by the business human. Nothing is rewritten.
• Schema: 3i to 3j adds thread_shares only. A re-pin past a schema bump needs a --migrate window with Jason, and row 185's backup before activate covers it.
• Rollback before any share is written: activate the previous copy with the store restored from the pre-activate backup. A 3i copy refuses a 3j store, as it does for every bump.
• Rollback after shares are written: the same restore loses shares made since the window. Grants are in access.json and survive. Users re-share. Row 181's restore guard counts thread_shares, so the loss is shown, not silent.
• To keep that window small, the build splits (section 9): 193a, 193b1, 193c and 193d have no schema change and can go live in any window. 193b2 carries 3j.

8. Tests and mutants

Bus, each in packages/bus/tests/ (193b1: viewer, mixed grants, board reads, the 5.7 message filter and governance pin; 193b2: shares, the share exception to the filter, migration):

• Viewer: each allowed verb works, every other verb refuses access-refused, including thread.create, thread.open, thread.send and thread.share.
• Mixed grants: collaborator on project A and viewer on B. Create in A works, create in B refuses.
• Downgrade: not here. FED R4 owns the level-loss test and its mutant (r4.4, mos-1020, N3).
• Shares: owner shares with user:<id>, the user reads thread.messages and gets thread-not-owned on thread.send and thread.open. Share with * reaches every covered user and the owner. Share with a user whose grant doesn't cover the project or instance refuses share-not-covered.
• A share never widens: the target's grant drops the project, the next read refuses.
• Revoke, expiry and an invalid file each end share reads on the next request. The 30 s timer and access.reload paths each have a case.
• A revoked thread owner hides the thread from sharees.
• Unshare ends access. Share, unshare, share again leaves it shared (latest row wins).
• Non-owner thread.share, thread.unshare, thread.shares refuse. Tester refuses on all three.
• thread.list plain shape unchanged. thread.list {shared: true} returns only readable threads.
• Board reads refuse users and viewers.
• Governance pin (B1, sage-1368): a user-thread run raises a decision; it shows in the owner's decisions recent with its question text, and inbox lists it when routed to the human; the run's role claim shows in the owner's agents, its task write in tasks, and its record.write in project.file (B3, sage-1373); the user's message bodies stay hidden from the owner's trail and replies. The test names each item of the 5.7 user sentence, so the sentence and the pin match.
• trail, for the owner, a reader session and the tester (193b1): a user's thread message as subject fails message-not-found; a decision trail that reaches such a message omits it, its deliveries and its events. Once the thread is shared with the owner, the owner's trail shows it.
• replies, same three sessions (193b1): a hidden id fails message-not-found; hidden replies are dropped. The owner's own and the tester's threads are unchanged.
• Migration: a 3i store with threads migrates to 3j, row counts unchanged, thread_shares empty and append-only (update, delete, replace each abort). Restore-guard and COUNTED include it.

Business (193a): R1 accepts viewer, refuses any other new level.

CLI (193c): mosaic access user add/remove and grant --level viewer refuse tester and agent callers, write a receipt line and call access.reload.

Webui (193d): a viewer has no composer or share control. With each UI check removed, the bus still refuses.

Mutants, each must be killed:

1. #readable rule 1 dropped (any covered user reads any thread).
2. Rule 2 dropped (a share widens the grant).
3. Rule 3 dropped (a revoked owner's thread stays visible).
4. Latest-row lookup replaced by "any share row" (unshare ignored).
5. (Moved to FED R4, N3: the level-loss mutant is R4's.)
6. Viewer allowed thread.send.
7. #threadRead used for thread.send (sharee writes).
8. share-not-covered check removed.
9. thread.share owner check removed (sharee re-shares).
10. A user allowed trail.
11. The trail filter removed (the owner reads a user's unshared message by id).
12. The replies filter removed (the owner reads replies in a user's unshared thread).

9. Build rows and order

Row	Work	Chains on	Schema
193a	R1 level check widened to viewer	FED R1 candidate	none
193b1	Bus: viewer verb list, per-grant level checks, users refused on board reads, the 5.7 trail and replies filter with #readable as owner-only	FED R3, R4 candidates, row 196 verifier	none
193b2	Bus: thread_shares, share verbs, the share rules of #readable, #threadRead, the 5.5 share filters	193b1 candidate	3j
193c	mosaic access user verbs and --level viewer, if R5 lacks them	FED R5 candidate	none
193d	Console: shared list, share controls, viewer read-only	FED R6, row 192 candidates, 193b2 for share controls	none

Sage ruled the split (sage-1354): 193b1 has no schema change and can go live first. 193b2 carries 3j, and Sage takes its migrate window to Mos when 193b2 is near. The 5.7 message filter is in 193b1 (Duckworth B2, sage-1368), so it is live before any user thread can be, whatever order FED R8 and 193b2 land in. 193b2 adds only the share exception. FED R4 chains on 193a (viewer level), and 193b1 chains on R4.

Coverage, settled in FED r4.1 (73677b87d, gizmoduck-0018, still under Duckworth's review). A grant's projects is ["*"] or bus project UUIDs (projects.id, broker.mjs:2306; threads.project references it). R1 exports one pure covers(grant, {business, project, instance}, now, {level}). Row 193 uses only that function and adds no second one (Sage confirmed, sage-1354):

• share reads (5.4 rules 2 and 3) and share-not-covered: covers(g, thread, now, {}), any level;
• thread.create, thread.open, thread.send, thread.share: covers(g, thread, now, {level: 'collaborator'});
• project.list and names for users: any level, as FED 3.5.

covers needs no further argument for row 193. If r4.1 changes in review, 193b1 follows it.

Follow-ups, not in this row:

• A read-only users and grants page for the owner in the Console.
• A second owner or admin level, if Jason wants one.
• An explicit, logged owner audit verb for user threads, only if Jason asks for one (sage-1354).

10. Gate

Per the brief: Duckworth approves this design, then the manifest. The bus, business, cli and webui suites and every scripts/test-*.sh pass on Sage's gate, and the section 8 mutants are killed. No test touches the live directories. No product code before Duckworth approves.