DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS /// DOCS
PROJECTS·OVERVIEW

Projects

A project groups everything related to one initiative — its Tasks, Pages, tables, Routines, and the Onniebots assigned to it. Projects let you scope context, permissions, and AI memory to a single slice of your workspace rather than the whole thing.

Projects can be public (all workspace members can see them) or private (only named project members plus workspace admins).

What a Project is

Each project is a row in the projects table. It belongs to a workspace and carries:

  • A name, optional description, icon, and color for display.
  • A status — one of draft, active, paused, completed, or archived.
  • Optional start date, end date, and target date.
  • A lead — one user responsible for the project.
  • An onnie_md context document — free-form markdown that any agent scoped to this project receives as background context, on top of the workspace-level context.
  • An is_private flag that controls whether the project falls back to workspace-wide visibility or uses its own project_members list.

Projects get an alias_id (12-char base-64 token) generated at creation, which appears in project-scoped URLs.

What lives inside a Project

Entities are linked to a project via a project_id foreign key. The following types can be scoped to a project:

Tasks. Any task can be attached to a project. The project Tasks view shows only tasks within that project; the workspace Tasks view shows all tasks regardless of project. Tasks without a project float at the workspace level.

Pages. Documents with a project_id appear in the project's content area. Pages can also exist at the workspace level (no project) or be nested under other pages.

Tables. A database table with project_id set shows up in the project view and obeys that project's read/write access rules.

Folders. Folders group pages, tables, and skills. A folder can be project-scoped or workspace-scoped.

Routines. Routines created inside a project are scoped to it and inherit the project's context. Workspace-level Routines span all projects.

Onniebots. Onniebots belong to a workspace, but you can configure one to operate primarily inside a project by scoping its instructions to that project's context.

Workspace memory. The engine stores scoped memory entries with a project_id, so an agent working in a project can accumulate context that doesn't bleed into other projects.

Creating and archiving projects

Creating a project. Any workspace editor or admin can create a project. The creator is automatically added as a project admin via a database trigger (projects_auto_admin_creator). Fill in the name, optionally set a lead, start/target dates, and choose whether the project should be private.

Private projects. When is_private is set, only members explicitly added to project_members and workspace admins can read or write the project's content. Public projects fall back to workspace-member visibility.

Archiving a project. Set the project status to archived. Archived projects remain in the database — their data is not deleted — but they drop out of active views. You can unarchive a project at any time by changing the status back.

Deleting a project. A project admin (or workspace admin) can delete a project. Deletion cascades to project_members. Tasks and pages with project_id set to this project have their project_id nulled (set null on cascade), so the content persists at the workspace level rather than being destroyed.

Project-level chat with Onnie

//NOTE

Coming soon. A dedicated project chat surface — where Onnie AI has the project's context loaded by default — is planned. For now, you can talk to Onnie AI in any chat and paste or reference project entities directly. Set the project's onnie_md to give the agent standing context about that project, and Onnie will use it whenever it works on entities scoped to that project.

Project roles

Project membership (project_members) uses the same member_role enum as workspace membership: viewer, editor, admin. The creator of a project is automatically added as a project admin. Workspace admins can always read and write any project, public or private, regardless of whether they are in project_members.

For a public project the underlying workspace roles govern access — workspace editors can write it; workspace viewers can read it. For a private project only the explicit project_members list (plus workspace admins) applies.

Project context for agents

Each project has an onnie_md field — a free-form markdown document that agents receive alongside the workspace-level onnie_md whenever they work on entities scoped to that project. Use it to describe the project goal, its conventions, the people involved, and any constraints the AI should know.

For example: "This is the Q3 launch project. The lead is Alice. All task titles must start with a component prefix like [API] or [Frontend]. Never mark a task complete without a linked Page that documents the decision."

Agents that create or update tasks, pages, and records inside a project will pick up this context automatically.