Project
A project groups test specs and test reports within a workspace. You can create unlimited projects per workspace.
Test spec storage mode
When you create a project, you choose how its test specs are stored: DB mode or Git mode.
| Mode | Where test specs are stored | Best for |
|---|---|---|
| DB mode (existing) | KATATAN | Creating and managing test specs in the KATATAN UI or via MCP / CLI |
| Git mode | CSV files in a GitHub repository | Keeping test specs in the same repository as your code and reviewing them in the same branch and pull request (PR) |
In both modes, test execution (creating test reports, recording results, sharing, and webhooks) happens in KATATAN. Test reports are stored in KATATAN, not in Git.
The storage mode cannot be changed after the project is created. Existing DB-mode projects also cannot be switched to Git mode (a migration feature is planned).
Git mode
In Git mode, test specs are managed as KATATAN-format CSV files in a GitHub repository. Editing a CSV in the KATATAN table editor and saving it creates a commit, and you can create working branches and pull requests directly from the KATATAN UI.
- Only GitHub is supported.
- Repository content is viewed and edited with each user's own GitHub account permissions. Every member needs to sign in to GitHub once.
- Each test report records the file, branch, and commit of the spec it was created from.
For details on connecting a repository, editing and committing, running tests, permissions, and limitations, see Git mode.
Project settings
The project settings page has the following tabs:
| Tab | Description |
|---|---|
| General | Edit name, description, and visibility (public / private) |
| Members | Manage project members and send invitations |
| MCP tokens | Manage project-scoped MCP access tokens |
| Webhooks | Configure webhook notifications for test report completion |
| Dictionary | Manage reusable test data values (see Test spec) |
| Repository | Change or reconnect the linked GitHub repository (Git mode only; available to project Owners and workspace Owners) |
Visibility
| Setting | Who can access |
|---|---|
| Private (default) | Explicit project members only |
| Public | All members of the workspace |
Project roles
| Role | Permissions |
|---|---|
| Owner | Full control, including member management |
| Editor | Create / edit / delete specs, cases, and reports; manage MCP tokens and webhooks |
| Viewer | Read-only |
Workspace Owners and Editors inherit project-level edit permissions across all projects.
Users invited to a project who are not already workspace members are automatically added to the workspace as Guests, giving them access only to that project.
Deletion
A project can be deleted by workspace Owners, workspace Editors, and project Owners. A project that contains test specs cannot be deleted. Remove all specs before deleting the project.
MCP Tokens
MCP access tokens are project-scoped shared assets. Project Owners and Editors can create and manage tokens. Because tokens belong to the project—not to any individual—CI/CD pipelines never depend on a single person's account.
Token capabilities:
- Token rotation — regenerate a token with a configurable grace period (0–90 days) so old and new tokens overlap during the transition
- Scheduled rotation — automatically rotate tokens on a fixed interval (1–365 days) at a specified UTC time
- Token scopes — restrict each token to specific MCP tools (allowlist)
- Rotation webhook — notify an external system (CI/CD, Secrets Manager) when a token is rotated; the new plain token value is delivered in the webhook payload
Webhooks
Webhooks send a POST notification to an external URL when a test report is completed. Webhook configurations (URL and optional custom HTTP headers) are managed per project and can be assigned to multiple test specs.