Administration, guard rails and the demo

Four ways to be a user#

Organization → Users lists everyone, and each row carries one control that answers what they are to you:

Org admin — reaches every project without being granted any.
Standard user — reaches what they are added to, and nothing else.
Viewer — reads what they are added to, and writes nothing. A viewer signs in and works normally in every direction that doesn't change anything: they read boards, roadmaps, tasks, comments and history for each project they have been added to, and nothing else exists for them. They cannot be given a task, cannot comment, and cannot rename a label. They can subscribe to a task (§11) — following one is reading it, not writing to it, and a viewer watching a risk is exactly who the eye is for. The role is a ceiling (§12), so it holds however generous a project role they were given — which is what makes it one setting rather than an audit of every grant.
Two things follow from it, and the app enforces both. A viewer leads nothing: you can't make one a project lead or a team leader, and you can't turn a lead into a viewer — you'll be told what to hand over first ("Anna Fält leads 3 project(s)"). And a viewer can't be handed new work — but switching someone to Viewer takes nothing away: every task already on their name stays exactly where it is, and their project access is untouched, so switching them back restores them completely. A viewer takes a seat like anyone else — being read-only is not the same as being unpaid for.
Inactive — switched off. They reach nothing, and they stop taking a seat, so an empty desk costs nothing. Everything they ever did stays exactly where it is: tasks they created, comments they wrote and their name throughout the activity feed all still read normally, which is the difference between switching someone off and removing them. Work already assigned to them stays assigned; new work cannot be handed to them until they are switched back on. Switching someone on again is a seat claim like any other and is refused when the seats are full.

You can't switch yourself off — it would take effect at once with nobody left signed in to undo it — and you can't switch off the last admin, for the same reason you can't demote them.

Agent users#

An agent is a user that is not a person: no email address, no password. It is given a name and an API key, and that key is its login. Create one from the same Users page — choose Agent instead of Person, type a name, and the key appears once. Copy it then; only its fingerprint is stored, so it can never be shown again. (Mint a second key any time from the agent's row to rotate: move the client over, then revoke the old one.)

An agent is a user in every other respect, and that is the point:

It reaches only the projects you add it to — the same Viewer / User / Lead roles you give a person, on each project's own page. It can never be an org admin, so a leaked key is never more than the work it was trusted with.
It can be read-only. Set an agent to Viewer and its key reads and changes nothing, anywhere — which is what a reporting job, a dashboard or a status bot actually wants, and it is one setting rather than a per-project audit you have to keep right.
It has no plannable week. A person has a number of hours available each week and Qivo plans against it (§10); an agent doesn't, and pretending otherwise made the planning worse — an agent given the default week showed as over capacity and had its work spread across calendar weeks it didn't need. So its row reads "no weekly limit" instead of an h/wk field, its work is never stretched to fit, and it is never shown as overloaded. On the Team strip its row writes the hours it is committed to each week rather than a percentage of nothing. This is a simplification, deliberately: a real agent does have limits — a rate limit, a budget, a queue — but none of them is a number of hours in a week, so Qivo doesn't claim to know one.
It signs its own work. Tasks it creates and changes it makes name the agent in the activity feed, and comments it posts are authored by it — not an anonymous "Someone".
It takes a seat, and switching it to Inactive stops every key it holds at once, without your having to revoke them one by one.

The key opens both machine surfaces: the REST API and the MCP server, so one credential serves a script and an AI assistant alike. See docs/rest-api.md and docs/mcp.md.

The demo organization employs one, so you can see all of the above without creating anything: Testbench sits in the Users list beside the seven people, with the AGENT chip, "no weekly limit" where they have hours, and a role on the USB-C Charger project. Its key exists but nobody holds it — the seed generates a secret, stores the hash and discards the plaintext, so the demo can show a complete agent without shipping a live credential. To actually use it, revoke that key from the agent's row and mint your own.

Users & seats: Organization → Users is the only door into the org. Guard rails everywhere: you can't remove yourself, can't demote or switch off the last admin, can't delete the last team, can't exceed the seat count — switching someone back on is a seat claim and is refused when the seats are full. The page also lists your Guests — the outsiders invited to single projects (§12), each shown with the project and role it holds — apart from the roster, because they are not part of your organization and take none of your seats. Whether one costs you anything depends on whether they have a Qivo organization of their own (§12).
Signing up: anyone can create an account. If a colleague or a client has already invited that address, the waiting seat is theirs the moment they sign in; if nobody is expecting them, Qivo offers to create an organization with them as its first admin. Nobody can award themselves a seat in an organization that didn't ask for them.
Destructive actions don't use popup dialogs: dangerous buttons throughout are a two-click arm-then-confirm ("Click again — deletes N tasks") that disarms itself after a moment.
Team and project settings render read-only for those who don't run them, with explanatory hints instead of vanished controls; the Organization pages (Users, Billing, Labels, General) appear for org admins only. Teams is the one exception, and it is the same rule in a different place: anyone who leads a team reaches it, and it lists exactly the teams they can manage — creating and deleting a team stays an org admin's.
Billing shows the plan, seat usage and renewal (portal not wired in the prototype).
Demo: the seeded Voltcraft organization ships a cast of demo logins (maya@demo.local / qivo-demo, and more) spanning org admin, team team leader, project leads and users — grant someone Viewer yourself to try that seat — ideally in two browsers side by side to watch the realtime sync. Rebuilding the pristine dataset is a job for whoever runs the deployment, done with the deployment's own CLI (npx convex run …) — Qivo itself has no wipe-and-restore button. Deleting is always something you aim at a named project or a named team, always confirmed, and always checked against the rights you hold over that project or team. Be aware that deleting a parent project takes its sub-projects and their tasks with it, and deleting a team takes every project filed under it — so the scope of a delete is the tree below the thing you named, not just the thing itself.