Surfaced during the setup-wizard/accounts grill-with-docs interview (see docs/adr/0027 and docs/adr/0028 for the accounts/OAuth groundwork this depends on).
Vision from that conversation: spoolbook moves from single-user to multi-user, where some users have print access (can send/manage prints directly) and others can only request a print — a request tied to a "MakerLab" project (term not yet defined in CONTEXT.md, needs its own domain-modeling pass). An admin presumably approves/fulfills requests.
Not scoped yet. Needs its own /grill-with-docs session to define:
- what "MakerLab" actually means as a domain concept
- the
PrintRequest entity and its lifecycle (requested → approved/denied → fulfilled?)
- how a requester picks a MakerLab project to request against
- role model beyond the current single
Admin role (users.role column already exists and is reserved for this, see 0027)
Explicitly deferred by the user: "this release will be single user first. but design should respect the future state."
Surfaced during the setup-wizard/accounts grill-with-docs interview (see docs/adr/0027 and docs/adr/0028 for the accounts/OAuth groundwork this depends on).
Vision from that conversation: spoolbook moves from single-user to multi-user, where some users have print access (can send/manage prints directly) and others can only request a print — a request tied to a "MakerLab" project (term not yet defined in CONTEXT.md, needs its own domain-modeling pass). An admin presumably approves/fulfills requests.
Not scoped yet. Needs its own
/grill-with-docssession to define:PrintRequestentity and its lifecycle (requested → approved/denied → fulfilled?)Adminrole (users.rolecolumn already exists and is reserved for this, see 0027)Explicitly deferred by the user: "this release will be single user first. but design should respect the future state."