Exact Candidate Verification

Bridge has two deliberately separate check modes:

• bridge check --format json inspects the ambient working snapshot. It is an iterative developer check and includes staged, unstaged, and untracked files.
• bridge check --index --format json and bridge check --tree <tree> --format json are commit-grade checks of one exact Git tree. Bridge never switches between these modes implicitly.

Candidate and frontier

Candidate mode resolves:

• T0, the exact candidate tree (git write-tree for --index, or <tree-ish>^{tree} for --tree);
• F, the nearest ancestor tree with an explicit Bridge approval, or the tree supplied by --frontier for an explicit trust bootstrap.

Committed does not mean verified. A commit becomes a usable verified frontier only after a clear candidate check records an explicit approval:

bb bridge check --tree HEAD --frontier HEAD --approve --format json

Approvals are tree-specific records under Git-private Bridge state. The index is resolved again immediately before approval; if it changed during the check, approval fails.

Evidence

Actions returned by candidate checks are pinned to both trees:

{
  "op": "bridge/run-evidence",
  "args": {
    "id": "unit",
    "tree": "<T0>",
    "frontier": "<F>"
  }
}

Run the action as returned:

bb bridge run-evidence \
  --id unit \
  --tree <T0> \
  --frontier <F>

Bridge creates a synthetic detached commit for T0, checks it out in a disposable linked worktree, and runs the configured command there. Bridge-owned logs and receipts stay under the trusted evidence root at candidates/<T0>/, outside the disposable source worktree. Candidate checks ignore unrelated working-snapshot evaluation and workflow artifacts.

Candidate receipts contain:

• candidate and frontier tree IDs;
• profile, policy, and evidence-command digests;
• a content-based subsystem fingerprint;
• confirmation that the command did not modify tracked candidate files.

A receipt is usable only for the exact matching candidate context. Timestamp changes do not invalidate content; content or executable-mode changes do. Approval records identify the successful receipts by content digest, rather than treating the existence of a commit as evidence.

Governance and preparation

The candidate cannot weaken the rules that authorize it. Bridge reads the profile and policy from F; candidate changes to either are reported as failed governance obligations, and evidence execution is refused. Approve a governance tree explicitly before using it as the frontier for later code changes.

Candidate worktrees begin with tracked T0 content only. Bridge does not copy untracked or ignored files from the developer workspace. Evidence commands may perform deterministic preparation using tracked scripts and external caches. Use the same preparation in CI after checking out the exact candidate SHA.

Workflow adapters

Typical local flow:

bb bridge check --index --format json
bb bridge run-evidence --id <next-id> --tree <T0> --frontier <F>
bb bridge check --index --approve --format json
git commit

bridge install-hooks installs candidate-aware pre-commit and pre-push hooks at the hooks path resolved by Git, including from linked worktrees. Hooks are an optional project-policy adapter, not part of Bridge's core semantics.

Vis independently treats coding-agent commits as a high-risk modality. Its Git adapter computes and preserves T0 while the Bridge extension contributes a lifecycle-owned semantic approval hook; neither Magit nor Bridge parses the other's protocol. This enforcement does not depend on repository hooks or CI. Enabling Vis's unrestricted shell is a deliberate escape from Vis-managed Git operations.

When project policy includes CI, check the exact pushed commit or merge candidate, run its pinned evidence actions in clean candidate worktrees, then approve and publish status for that SHA. A protected base SHA may be passed as the explicit frontier when CI does not retain local Git-private approval records.