Updating the Baseline
nolapse baseline update advances the stored baseline to match the current coverage measurement. Run it after a PR that intentionally improves coverage and you want future runs to compare against the new, higher number rather than the old one.
When to update the baseline
Section titled “When to update the baseline”Update the baseline when:
- A PR adds new tests and coverage increases deliberately.
- You want to lock in a coverage improvement so regressions are measured from the new level.
- A refactor removes dead code and coverage rises as a side effect, and you accept the new number as the floor.
Do not update the baseline to escape a failing nolapse run. The baseline is a floor, not a target — raising it to hide a regression defeats the purpose of enforcement.
The two-step workflow
Section titled “The two-step workflow”nolapse baseline update does not re-run coverage itself. It reads from the .nolapse_run_state file written by a preceding nolapse run. The workflow is always:
# Step 1 — run coverage and produce run statenolapse run --repo .
# Step 2 — advance the baseline using that run statenolapse baseline update --repo .These two commands must be run in order. If you run nolapse baseline update without a prior nolapse run in the same repo, it will fail.
What nolapse baseline update does
Section titled “What nolapse baseline update does”-
Reads
.nolapse_run_state— a JSON file written bynolapse run. Example contents:{"coverage": 84.10, "head_sha": "a3f8c21d4e6b09f1c2d3e4f5a6b7c8d9e0f1a2b3"} -
Appends a new entry to
.audit/coverage/baseline.mdin the append-only log format:2026-03-01T14:22:05Z | 84.10% | a3f8c21d4e6b09f1c2d3e4f5a6b7c8d9e0f1a2b3 -
Updates the header block in
baseline.mdso thecoverage:andcommit:fields reflect the new baseline. -
Creates a git commit with the updated
baseline.md.
The .nolapse_run_state dependency
Section titled “The .nolapse_run_state dependency”.nolapse_run_state is a transient file. It lives at the repo root and is overwritten on every nolapse run. Its schema is:
{"coverage": 84.10, "head_sha": "<40-char-sha>"}.nolapse_run_stateRunning without a prior nolapse run
Section titled “Running without a prior nolapse run”If .nolapse_run_state does not exist when you call nolapse baseline update, the command fails:
error: .nolapse_run_state not found run `nolapse run` first to generate coverage stateAlways run nolapse run immediately before nolapse baseline update in the same pipeline step or shell session.
Git history format
Section titled “Git history format”nolapse baseline update makes one git commit. The commit touches only .audit/coverage/baseline.md. Over time, this produces a clean, auditable history of baseline changes:
a1b2c3d chore(nolapse): update baseline to 84.10% [2026-03-01]9f8e7d6 chore(nolapse): update baseline to 83.40% [2026-02-14]5c4b3a2 chore(nolapse): update baseline to 82.50% [2026-01-15]You can inspect this history with nolapse audit list or directly with git log -- .audit/coverage/baseline.md.
# Update baseline in the current directorynolapse baseline update
# Update baseline in a specific reponolapse baseline update --repo /path/to/my-serviceRecommended CI pattern
Section titled “Recommended CI pattern”In most setups, nolapse baseline update is run manually or in a dedicated post-merge job — not in the PR check itself. A typical setup:
- PR check job — runs
nolapse run. Fails if coverage regresses past thresholds. - Post-merge job (on
main) — runsnolapse runthennolapse baseline updateafter the PR is merged and coverage is confirmed.
This ensures the baseline only advances after code has landed on the main branch, not speculatively during review.