Security and trust

How repository access works

Test Chronicle runs inside a checkout you control. Use the local CLI on your machine or the Test Chronicle GitHub Action in your CI runner.

Test Chronicle does not install a GitHub App or independently browse your repositories. The agent reads supported test files and Git history from the checkout, extracts metadata, and sends an authenticated sync payload to the Test Chronicle API.

You control which repository is checked out, where and when the agent runs, and which Test Chronicle credential it receives.

Customer controlled

Your environment

Local or CI

1. Step 1

   Repository

   Checked-out Git history

2. Step 2

   CLI or Action

   Runs in your environment

3. Step 3

   Metadata extraction

   Test history is analysed

Authenticated handoff

Authenticated service

Test Chronicle

Extracted data

4. Step 4

   Authenticated API

   Project credentials required

5. Step 5

   Metadata storage

   Extracted records are stored

6. Step 6

   Dashboard

   Visible to authorized users

What data is synced and stored

The sync API accepts:

• Repository URL and detected frameworks.
• Test file paths, test names, line numbers, and tags.
• Commit hashes, messages, authors, and dates.
• Added, deleted, renamed, and maintenance classifications.
• Change details, sync timestamps, counts, and the last synced commit marker.

Test Chronicle stores this metadata to build the project timeline, test and file views, contributor activity, trends, and sync state. It also stores the account, team, and credential records needed to operate the service.

Test Chronicle does not have fields for complete source files or raw test-file bodies. It stores the extracted metadata listed above, including structured change details produced by the agent.

Do not place secrets or sensitive personal data in repository URLs, file paths, test names, tags, commit messages, or author fields because those values may be synced.

GitHub permissions and secrets

The GitHub Action runs against the checkout created by your workflow. The recommended workflow permission is:

permissions:
  contents: read

This allows actions/checkout to read repository contents and history. fetch-depth: 0 supplies the history needed to connect test changes to earlier commits; it does not add GitHub API permissions.

The documented workflow does not require write access to repository contents, issues, pull requests, deployments, administration, or organization membership.

The hosted Test Chronicle service cannot independently open GitHub Actions secrets. The agent runs with the access of your local user or CI job, so pass only the Test Chronicle credential needed by the sync step.

Access, revocation, and deletion

• Browser-approved CLI login creates a credential linked to the selected project.
• Project-scoped tokens cannot sync a different project.
• Project, team, and personal credentials are checked using stored hashes rather than retained plaintext values.
• Removing or revoking a credential prevents later authenticated syncs.
• Removing the workflow or its Test Chronicle secrets stops automated repository syncs.
• Server routes check project ownership or active team membership before returning project data.
• Application tables use restrictive row-level security policies alongside server-side authorization checks.

Project owners can delete a project from project settings. Users can delete a personal account and its personal projects after resolving any team ownership. Active history older than 12 months is moved to archive tables, so this page does not promise immediate removal from archives or infrastructure backups.

Service providers

The current application uses Supabase for authentication and application data, Vercel for application hosting and related platform services, and Stripe for Team-plan billing. The CLI and GitHub Action are distributed through npm and GitHub.