Which findings should `check --strict` block a merge on?

Gap: issue-9cb85759076d Blocking: yes · Rank: 4 · Asked: 2026-07-26 · Answered: 2026-07-26 Authority: repo maintainer (directed the fix; proposed severity split adopted as-is)

Question¶

check --strict exits 1 on any finding, and orphan fires for every document with no relations — the default state of a new document — so the advertised CI gate fails on a healthy corpus. Which findings are meant to block a merge?

What the system does today¶

OBSERVED: a fresh store with two unrelated, otherwise-healthy documents exits 1 from two orphan findings. No severity, no --only <kind>, no ignore file. Evidence: cli/app.py:439-440, graph_checks.py:173-192.

Proposed answer¶

Severity on the finding: error = duplicate-id, dangling, malformed; warning = orphan, cycle, layering, stale, unknown-type. --strict fails on errors; --strict=all keeps today's behaviour.

Why it matters¶

A team that adopts the documented gate gets a red build on day one and will remove it — which also removes the duplicate-id detection that is the gate's stated purpose and the only automated defence against issue-88dd653b9f39 and issue-96b03701503b.

Answer¶

ANSWERED 2026-07-26 by implementation: errors = duplicate-id/dangling/malformed, warnings = orphan/cycle/layering/stale/unknown-type, --strict gates on errors, --strict-all preserves the old behaviour. See issue-9cb85759076d resolution.

---

Migrated from the discovery question queue (Q-004); the queue itself now lives in this store.