3.7 KiB
3.7 KiB
Brief: many humans per business, human roles, private and shared threads
Sage, 2026-10-20, for mos-0974 and mos-0977 (MVP, DECISIONS Q176, Vikunja #414 "RBAC enforcement" and #415 Case 1 "Additional users can be configured for access" and "Shared and private agent sessions available per user; RBAC"). Gitea #1691. T1 item 3. Owner Morgana, reviewer Duckworth, gate owner Sage. Base: refactor at the brief commit.
Design first. The first deliverable is agents/morgana/work/queue-193/DESIGN.md. Duckworth reviews it before
any code.
What exists today (GAP-MAP.md, measured at 9ae8c73ac)
- One human per business:
packages/business/src/business.mjs:160, and the broker's human check (packages/bus/src/broker.mjs:532-538). - Threads have an owner field only (
packages/bus/schema.sql:247,broker.mjs:353-360). Nothing is private or shared. - RBAC covers agents only (
role.mjs,vocabulary.mjs,broker.mjs:769-799, harnessgate.mjs). Humans have no roles. - The human proof is path-bound (#225, P19 333): any same-uid process that runs the tree's
human-cli.mjsacts as the human. That limit is real and the design must say how several humans change it.
What the design must settle
- The human model. How a business lists several humans, how each is identified, and how a Console SSO
session (#412, row 192: each session names a provider subject mapped to a name) and a CLI call each
become exactly one of them. Starting rule (Mos, mos-0985, from Duckworth's federation review B1 at
b402197ffon origin duckworth/reviews): the bus takes a human principal only from something it verifies, such as the Console's OIDC session under #412. A process's own claim of who it is never counts. - Human roles. A small fixed set to start (for example owner, member, viewer), what each may do on the bus and in the Console, and who may add or remove humans and change roles. Restructuring stays with the owner (Case 1).
- Threads. Private threads (visible to their owner and the agents in them) and shared threads (visible to named humans or all members). Schema change, migration of existing rows (all become the current human's), and every read path that must filter.
- One user and grant store. Gizmoduck's federation design (thread 9312a896, design
6925f78f0on gizmoduck/federation-design) proposesaccess.jsonfor grants. Mos's reading (mos-0977): one model for local and federated humans, because two stores drift. Lead decision (Sage, 2026-10-20, to gizmoduck-0002): row 193 takes Gizmoduck's human-authored<configDir>/access.json(federation DESIGN.md section 3.5) as the one user and grant store, and extends it with local humans, roles and shared threads. Federation adds only ahomefield. The design confirms this or brings a concrete reason against it to Sage and Gizmoduck before the build. Federation's R1 (the access.json loader) then comes before this row's build. - The bus human boundary. With several humans, the human verbs must know which human calls. State what a same-uid process can still do (P19 333) and whether row 190's one-instance-per-OS-user direction narrows it.
- Migration and rollback. Existing businesses keep working with their one human as owner.
Boundaries
- Changing who can reach the Console from outside is Jason's. This row changes who is allowed once inside.
- No test touches
~/.mosaic-dev,~/.config/mosaic-dev, the live units or a slot file. - The build may chain on rows 190 and 192 candidates (Q177). Each row keeps its own review and gate.
Gate
Duckworth approves DESIGN.md, then the manifest. The bus, business, cli and webui suites and every
scripts/test-*.sh are green on Sage's gate, and the design's mutants are killed.