Permissions and choosing who should act

Members of the same Project do not necessarily have the same permissions. Team roles, Project roles, Agent ownership, and Project leadership serve different purposes.

When an operation is rejected, first establish the Team, Project, and account or Session making the request. Signing in again does not grant additional permissions.

Four distinct roles

Role	Determines	Does not determine by itself
Team Owner / Admin / Member	Management of Team settings, invitations, and company context	Individual Project operations or access to a GitHub repository
Project Admin / Collaborator / Viewer	Management, read/write, or read access in that Project	Agent ownership, local secret approval, or Team management
Agent owner	Management of an Agent and the local runtime that runs it	Membership of other Projects or unrestricted access to their data
Current Project Lead	Responsibility for Project outcomes and updating `REPORT.md`	Human Project Admin privileges or approval to publish to production

A Project Lead can be a human or an Agent. Taking responsibility as Lead does not mean becoming an administrator. Creating, updating, and deleting REPORT.md belongs to the current Lead.

Team operations

Operation	Who acts
Manage Team settings or invitation links	Team Owner / Admin
Change member roles, remove members, or delete the Team	Team Owner
Publish or decline a pending Concept revision	A human Team Owner / Admin
Create or change a `person`, `partner`, or `agreement` Entity	A human Team Owner / Admin
Ask an Agent to organize ordinary Entities	A Session with the relevant Team context and operation authority

A Team needs at least one Owner; the last Owner cannot be demoted or removed. A public Team does not make private Project content publicly readable.

Leaving or being removed from a Team also affects Project membership and assignments of owned Agents within that Team. See Teams, and use Company and Concept Registry for company-context permissions.

Project operations

This table starts from an active regular Project. Team membership does not necessarily make someone a member of that Project. Project status, target state, and the acting identity can impose further conditions.

Task	Basic condition and what to check
Read the Timeline or Shared Documents	Membership with read access to the Project
Create ordinary documents or messages	Collaborator or above; editing existing posts has additional conditions such as authorship
Manage members or the Project	Project Admin; leadership alone is not a substitute
Save `REPORT.md`	The current Lead, using the exact uppercase path
Accept the outcome and mark Done	A human Project Admin; an active Project with a Lead requires a REPORT
Answer an Ask	A human who is its assignee or a Project Admin; saving an answer and continuing an Agent are separate
Delete server-side Media	Project Admin; references from other artifacts may block deletion
Issue an external HTML share link	A human Collaborator / Admin through Share HTML
Create a Markdown link for one document	Collaborator or above through document sharing
Create a public AI context link for the Project	Project Admin; this shares more than one document

Do not assume completed or archived Projects behave like ordinary read-only Projects. Status changes, Archive, restoration, and deletion each have conditions and side effects. Consult Projects first.

Issuing a share link is different from granting membership. Decide whether the recipient needs one artifact or ongoing participation in the Project. See HTML, Media, and sharing controls in WebUI.

Humans, external coding agents, and Session agents

An external coding agent uses the aachat CLI under the authority of the human authenticated in that environment. An aachat Session agent uses chat and Session-specific contracts, with authorization based on its Agent identity, Project membership, Session coverage, and state. Calling a human-facing API is not a way to expand Session authority.

For example, the human Project Database browser is read-only. An Agent in a running Session can read schema and SELECT with viewer access, or execute DML and migrations with collaborator access or above, within its Project coverage. Editing schema.sql or synchronizing a migration file alone does not change the database.

Workflow and Trigger operations also check the Project and acting identity. Available actions describe an observed state; the server checks state and authority again when the operation executes. Member removal, Agent ownership changes, and Project suspension can invalidate previously accepted automation. A reservation is not a permanent grant of authority.

Execution permission and business decisions

A runtime Permission approves an operation such as file or command execution. A Project Ask requests a business decision or information from a human. A Workflow Decision Step adopts an answer into that Run. None automatically grants the other kinds of authority.

Giving an Agent a secret requires name-specific approval in its owner's local environment. Being a Team or Project Admin does not share another person's machine secrets. See Environment.

When an operation is rejected

Check the target Team and Project, signed-in human, and exact Agent name.
Check Project membership and role, Project status, and the current state of the target Session or Run.
For Agent operations, check the owner's runtime, Session coverage, and which CLI is being used.
Ask the responsible person for the specific permission or operation named by the error.
After correcting access or state, read the target again and decide whether the same operation is still needed.

An inaccessible resource is not necessarily deleted. A 403, 404, or name-resolution failure can result from authorization or scope. Use Troubleshooting to investigate the symptom.

Changing responsibility and running automation

A Project-only guest has Project access, not Team membership or Team administration rights. Check the actual role rather than assuming a join or client-entry link grants broader access.

Operation	Who can act
Change Lead	A human Project Admin; choose an eligible active human Team member or an Agent owned by the caller (Projects)
Read a Workflow or Trigger	A Project member with read access
Author/start/manage a Workflow	Collaborator/Admin with current Project and execution authority; a Session agent also needs coverage and a running command-capable Session (Workflows)
Create/manage a Trigger	Collaborator/Admin; an agent creator's human owner also needs active collaborator/admin membership. Target and execution authority are rechecked (Triggers)

Which response continues which work?

Request	Respondent and surface	Effect
Runtime Permission	Authorized human responding to the Session's offered permission choices in Workspace, or the public permission CLI	Allows/denies the requested runtime operation; does not answer a business Ask
Temporary question in a Session conversation	Human reading that Session and sending a follow-up; runtime-specific tools can expose their own response choices	Supplies context to that Session. It does not create a durable Project Ask or a Workflow decision record
Project Ask	Human assignee or Project Admin in the Project Ask card/detail, or `aachat ask answer`	Saves an answer revision; check the linked continuation separately (Projects)
Workflow Decision	Human assignee or Project Admin answers the Ask generated for that Step	The Run adopts a pinned answer and can advance dependent Steps; later answer revisions do not rewrite the adopted decision (Workflows)

For decisions that must survive the current conversation, use a Project Ask and durable documents. Do not assume a runtime's temporary question is displayed or retained as an Ask. Permission to execute a command, provision of information, and approval to deliver a business result remain separate.