Automation and reviewed baselines

Strict coverage policy

A successful process exit is meaningful only when the selected source was actually covered. Start automation with explicit policies:

mori scan --format json \
  --profile review \
  --min-file-coverage 0.95 \
  --max-zero-fragment-files 2 \
  --fail-on-parse-diagnostic \
  .

--min-file-coverage divides fragment-producing files by analyzed supported files. Generated exclusions remain visible but do not enter the denominator. --max-zero-fragment-files=-1 disables that limit. The broader --fail-on-warning rejects any discovery, parsing, resource, focus, or coverage warning.

Coverage-policy failure writes the report and exits 4. Match-policy failure exits 3; coverage failure takes precedence.

Changed-file gates

For a local pre-commit gate, scan exactly the index and require every non-deleted staged path to participate:

mori review staged check --format json .

The report records an index digest and explicitly excludes unstaged and untracked bytes. A configured or explicit baseline is read from that same index snapshot and must be a tracked regular file inside the worktree; an unstaged baseline edit cannot change suppression. --include-focused bypasses ordinary ignore rules for staged paths, while explicit excludes, generated policy, language support, and resource limits remain visible coverage boundaries.

Keep the whole repository as the comparison universe while requiring review of groups involving changed source:

mori scan \
  --profile review \
  --changed-since origin/main \
  --fail-on-focused-match \
  .

Mori never fetches the revision. CI must fetch enough history for the merge base to exist locally. Use one explicit --changed-worktree PATH=REVISION per additional Git root.

--fail-on-match fails for every unsuppressed result at the selected threshold. Prefer the focused policy during initial adoption so old untouched candidates remain visible without blocking unrelated work.

For an explicitly owner-authorized one-commit exception, create the local receipt through the same canonical staged-review contract as the enforcing scan:

mori review staged acknowledge --accept-focused .
mori review staged check \
  --review-receipt "$(git rev-parse --git-path mori/staged-review.json)" .

The receipt keeps findings visible and is bound to the exact HEAD, index, scan profile, staged inclusion and coverage contract, tool, normalization version, and complete focused identity set. It does not create durable suppression. The lower-level scan --staged and review acknowledge --staged forms remain available for custom policies; prefer the canonical commands for commit gates.

Accept intentional similarity selectively

Inspect both source locations before accepting an identity:

mori baseline add \
  --baseline mori-baseline.json \
  --identity <content-pair-id> \
  --classification intentional \
  --note 'Reviewed with the owning team' \
  .

Then load the baseline explicitly:

mori scan --baseline mori-baseline.json --fail-on-match .
mori baseline prune --baseline mori-baseline.json --check .

Use baseline edit to update a note or classification and baseline remove to revoke acceptance. baseline update is preview-only unless --accept-all is explicit.

Schema-4 baselines bind acceptance to a digest of the effective selection, threshold, dialect, fragment, exclusion, ignore-content, resource, and coverage policy. Profile mismatches fail closed. Legacy baselines remain readable but must be explicitly migrated before mutation. Schema 3 remains readable and requires migration before mutation; schema 4 also supports false-positive classification. Migration changes the recorded contract, so review the reported profile differences before explicitly accepting it.

For normalization 12 to 13, ordinary scans continue to reject old acceptance. After reviewing the normalization change, baseline migrate --accept-profile can read that specific prior version, perform a complete unsuppressed scan, and write the current contract. It preserves existing decisions and metadata and reports how many retained entries are currently stale; it does not accept new identities. Failed coverage or mutation-completeness checks leave the file intact. Other unsupported normalization versions require separate review/regeneration.

Baseline decisions apply only to matching content identities and their recorded scope. Changed code can produce a new identity and require fresh review; an old acceptance must not silently follow it. Use baseline prune --check to inspect stale entries and baseline update to preview candidate additions. These commands do not authorize accepting every new finding. Keep intentional UI symmetry classified separately from source-verified duplication.

Baseline mutation refuses failed coverage policy, truncated reports, and warnings unless every reviewed warning kind is explicitly allowed. Never use a baseline merely to hide noisy or out-of-scope source.

Accept several reviewed identities in one scan

Batch acceptance is available in Mori v0.34.0 or later.

Repeat --identity to accept a reviewed batch using one complete validation scan and one atomic baseline write:

mori baseline add --baseline mori-baseline.json \
  --identity <first-reviewed-id> --identity <second-reviewed-id> \
  --classification intentional .

Every identity must exist in the active scan. If any identity is missing, nothing is written. Duplicate identities are accepted once. The supplied note and classification apply to every selected identity, so use separate batches for different decisions. Inspect each finding before accepting it. Existing baseline profile mismatches are rejected after discovery, before parsing or comparison. This changes no baseline document schema.