Auto‑Merge Provisional Fixes After Harness Pass

Audits stall when the repair never leaves the report

A typical audit ends with a list of findings. The list is exported, reviewed, and then archived. The code that caused the finding stays untouched. Technical debt therefore continues to accrue. The detection works; the failure is the missing step that turns a provisional fix into a live change.

Provisional verdicts give a concrete signal

When the certification harness runs a provisional fix it returns one of four verdicts: CERTIFIED, PROVISIONAL, INCONCLUSIVE, or FAILED. A PROVISIONAL verdict means the harness exercised the artifact and observed no violation of the input contract. It does not assert full correctness and it should only be used for fixes that do not require architectural changes or exhaustive correctness guarantees. The verdict is repeatable, computed, and attached to a specific build intent, so the system can verify that the intent has not been altered before merging.

Auto‑merge workflow that respects the harness

1. An audit engine discovers a violation and emits a repair suggestion.
2. The suggestion is packaged as a provisional artifact and submitted to the harness.
3. The harness returns PROVISIONAL.
4. An automation script reads the verdict, checks the published checksum, and calls the same HTTP API used by the typed client to create a merge commit.

import { mergeProvisional } from '@shpbl/sdk';
if (verdict === 'PROVISIONAL') {
  await mergeProvisional({ intentId, checksum });
}

The script runs in the same CI environment that executed the harness. Human review may still be required for changes that touch architecture or need full correctness; the script auto‑merges only when the verdict is PROVISIONAL and the fix is confined to non‑architectural adjustments. If the harness later returns CERTIFIED, the same script can promote the merge to a protected branch. If the harness returns FAILED or INCONCLUSIVE, the script aborts and raises a ticket for manual investigation.

The TypeScript client is published as @shpbl/sdk — <https://github.com/shpbl/sdk>.

Turning a report into a live improvement

The loop described above closes the gap highlighted in the pillar post /blog/closing-the-loop-from-repository-audit-to-merged-repair. The audit produces a finding, the harness validates a provisional fix, and the auto‑merge finalises the repair. The result is a measurable reduction in technical debt.

The approach does not claim that every audit will be auto‑merged. Findings that require architectural changes or that the harness cannot verify still need a human decision. What the workflow guarantees is that any fix the harness can label PROVISIONAL will not remain in a dangling branch.

Monday action

Open your CI pipeline configuration. Add a step that watches the harness endpoint for PROVISIONAL verdicts. Hook that step to the merge API shown in the SDK snippet. Run the pipeline on a recent audit run. If the merge succeeds, you have turned a stale audit repair into a live change before the end of the day.