Bring a project you already have

Most projects arrive this way. Nothing about how you build changes; DoneMark learns to read what your CI already does.

What DoneMark needs from your repository

Three things, and it will tell you which you already have.

1. A test run that produces a machine-readable report — one entry per check, with its full name and whether it passed.
2. A workflow that publishes that report under the names DoneMark looks for, along with the same report from the code as it was before the change, and the coverage.
3. A key for your agents, as a repository secret. DoneMark records its name and never its value.

The full shape is in What your CI must publish.

Step 1 — point DoneMark at the repository

On the project door, choose an app that exists and give the repository's address.

Step 2 — install the witness

DoneMark asks you to install its GitHub App on that repository — on GitHub it is still named Constat, and the button says Install the Constat App. It reads your code and never writes it. The screen prints what it may do and what it may not, before the button:

It may read contents, read Actions runs and artifacts, start and cancel runs of your own workflows, read checks, read pull requests and their files, read secret names, and read open issues when you ask it to bring your backlog in.

It may not read a secret's value, write a file, push a commit, merge, or reach a repository you did not install it on.

You choose which repositories it sees. You can remove it from GitHub at any time.

Step 3 — read the readiness page

DoneMark now reads the repository and says one of:

• Ready — its CI already publishes everything. Skip to step 5.
• Missing — it names each piece in plain words.
• A dead end — DoneMark has no reporter for that language yet, and says so rather than letting you find out after an attempt.

Step 4 — add DoneMark's files

Where something is missing, the page offers one press: Add DoneMark's files, and let its runner open pull requests, in my name. You sign in to GitHub for that one act; DoneMark uses the permission once, to open the pull request, and keeps nothing.

Or run the exact line for your project in a terminal:

npx @constat-io/cli connect owner/repo

It runs on your computer, signed in to GitHub as you. It writes the files to a branch and opens a pull request in your name — DoneMark's own credential cannot write to your repository, which is what keeps what it reads evidence rather than something it arranged.

Read the pull request. Merge it when you are happy. DoneMark notices the merge the next time it looks, and the readiness page turns green on its own.

Everything the tool would write is also printed on the page, file by file, if you would rather add them by hand.

The tool never asks for a secret's value. It prints the name and where to put it, and that is all it knows.

Step 5 — add the key, and test it

Paste your agent's key here, then Seal it and store it on GitHub, in my name: the key is sealed in your browser with GitHub's own public key for the repository before it leaves, so DoneMark never sees it. Or put it in the repository's Actions secrets yourself, under the name the page prints.

Then Test the key. Your runner makes one real call with it, and the page says what came back — Works, Refused, or why it Could not test. Dispatch waits until the key has passed.

Step 6 — decide where attempts run

By default they run on GitHub's machines. If you have a runner of your own, give its label on the project's settings and the runner will stand there instead, asking DoneMark for work every thirty seconds — no button to press.

What has changed in your repository

A workflow that asks DoneMark for work and runs your agent. A workflow that publishes what your CI already ran. Nothing that changes how your software is built, tested or deployed.