Design.BoundaryFrozen

Flags any source file inside a boundary marked frozen = true in cofferdam.invariants.toml. A frozen boundary is an architectural intent — "no new code here" — and this check makes that intent visible at review time rather than blocking work outright.

Configuration

[boundaries]
"src/legacy/**" = { frozen = true, reason = "see ADR-0007" }

Every file matching the glob gets one finding, with reason echoed in the message. The check itself has no notion of new versus old: on a whole-project run it names the entire boundary, which is the honest answer to "what is frozen?" but not the one you want on a pull request.

Enforcing the delta

Two flags turn the census into a gate, and they answer different questions.

--since asks what this branch touched:

cofferdam check --since origin/main --only Design.BoundaryFrozen --fail-on low

Findings are scoped to files in the diff, so a branch that stays out of the frozen area reports nothing and one that edits a single file there reports that file alone. The whole project is still analysed — only the report is narrowed — so cross-file checks keep their full graph. This is the recipe for a pull-request gate.

--baseline asks what has been added since the day you froze the area:

cofferdam baseline write --output .cofferdam/baseline.json   # once, at freeze time
cofferdam check --baseline .cofferdam/baseline.json --fail-on low

The files already inside the boundary are recorded and thereafter marked baselined; only later additions count as new and trip --fail-on. This is the recipe for a repository that means to shrink the frozen area over time.

Suppression

Use a severity override or an inline // cofferdam-disable-next-line directive when the area is intentionally still active during migration work.