Settings

Settings live on two levels: the organisation and the project. The rule is simple — the organisation holds what is common to all projects, the project holds what belongs to one product.

Roles in an organisation

An organisation role and a project role are different things. An organisation administrator has full access to every project, even one where they are not listed as a member. The reverse does not hold: a project manager does not run the organisation.

Organisation settings

• People — invitations, roles, removal.
• GitHub — installing the app and the list of repositories it can reach. Once per organisation, see GitHub.
• Trust profiles — what agents may do, see Security.
• Roles — which assignee roles exist at all: developer, sysadmin, designer.

Project settings

The table below is assembled from the settings schema itself: both the list and the defaults are the ones a project gets when nobody touches the setting. It cannot drift away from the system.

Setting	Default	What it does
Accept automatically	off	Accept the result without a human. Off by default, deliberately.
Require passing tests	on	Hold a task out of review until the agent reports its tests passed.
Require green GitHub checks	off	Refuse acceptance while GitHub checks on the pull request's latest commit are not green. This applies to acceptance by a human only: auto-acceptance on merge means GitHub already allowed the merge.
Send the task back when GitHub checks fail	off	A delivered task sits in review and the checks on its pull request's head completed as failures — the platform takes it off review itself and returns it to the agent, naming what failed. It spends an attempt: on the third return the task goes to "Failed".
Task budget, tokens	not set	How many live tokens (input + output) a task may cost before the platform says so. A warning, not a ceiling: work continues, while the managers get a notification and the card gets a mark. Empty means no budget.
Create a review task when a pull request opens	off	When a pull request opens, a "Review …" task appears on the board with a link to it.
Role for the review task	not set	Empty — the review task is created without a role and is visible to the whole project team.
Slack channel	not set	Where project events go: a task is picked up, finished, an agent asked, something waits for approval. Empty means the project runs on direct messages — a supported mode, not a fault.
Slack channel name	not set	The channel name at the time it was chosen, for display only. The identifier is the truth: channels can be renamed.
Tasks per agent at once	1	How many tasks one agent may hold at the same time.
Task lease, seconds	120	How long a lease survives without a sign of life from the agent. Once it expires, the task returns to the queue.
Task timeout, minutes	90	How long a task may stay in progress before it counts as stuck.
Reset agent context after N tasks	8	After how many tasks the agent starts from a clean context.
Branch name template	task/{key}-{slug}	The task key and a slug of its title are substituted in.
Commit message template	{key}: {title}	The task key and title are substituted in.

Listed separately, because these are not "a setting with a value" but screens of their own:

• Members — who works in the project, and in which role.
• Repository — picked from the connected organisation's list.
• Trust profile — which of the organisation's profiles applies here.
• Board — columns, saved filters, task templates.
• Notifications — which channels are enabled for the project.

Who may do what in a project

Permissions follow from the organisation role and the project role:

• Viewing a project's tasks is open to any member of it.
• Editing tasks — a member with the matching permission; an organisation administrator and owner always.
• Accepting and returning work is a separate permission, held by the manager. That is deliberate: acceptance is not the same thing as editing.
• Changing project settings — the project manager, an organisation administrator and the owner.

Deletion and the bin

Deleted tasks, documents and milestones go to the project bin, from which they can be restored. The bin shows who deleted them and when.