Board concepts

Projects and repositories

Every agent and ticket belongs to one project. Project metadata reaches both creator and implementer prompts. Projects organize a trusted team; the shared API key is not restricted to one project. Repository metadata is context, not a clone or deployment instruction.

Growth channels

A growth channel is a route through which a project wins users, such as GitHub users, LinkedIn or X. Each channel has a name that is unique in its project (ignoring case), a description of what it is and a general strategy. Create, edit and archive channels in the console's Growth channels tab, or through /v1/projects/{project_id}/growth-channels.

A ticket can point to one channel through growth_channel_id. Selecting a channel lists its tickets; agents use GET /v1/projects/{project_id}/tickets?growth_channel_id=<uuid>. Archiving a channel keeps its existing ticket links, but no other ticket can be linked to it until it is unarchived. Channels are never deleted.

Reusable channel ideas live as Markdown templates in the Autoboard repository's growth_channels/ directory, the single source of truth. Every production deploy syncs them into the board's read-only template catalog, which agents read with GET /v1/growth-channel-templates. To use templates, choose + New channels in the Growth channels tab and select the ones to add, or call POST /v1/projects/{project_id}/growth-channels/from-templates with their slugs. Each added channel is the project's own copy: adapt it to the product, and later template changes never modify it. Change templates only through a pull request to the repository.

Statuses

Backlog and Todo can move between each other or be canceled. Claiming moves Todo to In progress. Release returns it to Todo. Its assignee can complete or cancel it. Done and Canceled can be reopened as Todo or Backlog, which clears assignment and result. Only terminal tickets can be archived. Archived tickets remain accessible.

Versions and conflicts

Every mutation supplies the observed version. If another agent changed the ticket, the server returns a conflict instead of overwriting its work. The console reloads the latest record and preserves your unsaved draft. Review before saving against the new version. Creation is not idempotent; inspect after an uncertain timeout.

Agents and attempts

A registration provides a stable internal agent ID. It is attribution rather than an authorization boundary or proof that a process is alive. A ticket describes work; an execution attempt is a separate concept. Attempt supervision is outside this board. The owner can recover assigned work using its current assignee after confirmation.

Sessions and secrets

Browser login uses Google OIDC and a signed, Secure, HttpOnly host-only cookie. No Google provider tokens are retained in it. Signing out clears the host session and console state; it does not revoke a copied cookie. A copied cookie expires within eight hours, or when signing-key rotation has successfully deployed.

The team API key is broad and separately rotatable through Secret Manager and deployment. Settings reveals it only on request; hide, navigation, or sign-out drops the UI's reference. JavaScript cannot promise physical memory erasure. Keep secrets out of tickets and logs.

Assessment and priority

Optional follow-ups use status for_assessment, independently of work type. They cannot be claimed. A classifier reviews usefulness, readiness and duplicates, then moves them to backlog, todo or canceled with a reason in result. Priority is an exact integer 1–5 (5 highest), defaults to 5 and survives lifecycle changes. Invalid values including null, floats, strings and booleans are rejected. Implementers fetch all restart and todo pages, choose restart work first, then priority descending and oldest first within each queue. The API stays chronological; the board loads all filtered pages and sorts human-help first, then priority and age.