Co-change coupling from Git history: bricks that keep changing in the
same commits are coupled, whatever their requires say. The pairs worth
reporting are those with no dependency path between them, which is
coupling the source doesn't show.

Cohesion within bricks, from the symbols each definition references.

- Cohesion: references to the brick's own namespaces / references to any
  workspace namespace. References to other libraries don't count.

Connascence between bricks: the static kinds that can be read from
source. Connascence within a brick is expected; between bricks it is
coupling.

- Position: interface functions that other bricks call with many
  positional parameters, so callers depend on their order.
- Meaning: keywords used in more than one brick, which are usually map
  keys that the bricks must agree on.
- Algorithm: the same code, of at least some size, in more than one
  brick.

Error surface: the interface definitions of each component that can
throw. A definition throws if its body contains throw, or refers to a
definition that throws, in its own brick or another. Catching isn't
taken into account, so this is an upper bound.

Brick dependency metrics from namespace requires, after Robert Martin's
package metrics, adapted to Polylith: a brick depends on an interface, and
so on every component that implements it.

- Afferent (Ca): bricks that depend on this brick's interface.
- Efferent (Ce): interfaces this brick depends on.
- Instability: Ce / (Ca + Ce), undefined for a brick with neither.
- Abstractness: 1 - interface definitions / all definitions. A small
  interface over a large implementation is abstract; bases are 0.
- Cohesion: references to the brick's own namespaces / references to any
  workspace namespace.
- Shared keywords: keywords this brick uses that another brick also
  uses, usually map keys the bricks must agree on (connascence of
  meaning).
- Libraries: libraries outside the workspace the brick requires, and
  shared libraries, those another brick also requires.
- Error surface: a component's interface definitions that can throw,
  directly or through what they refer to.
- Untested interface: a component's interface definitions that no test
  in the workspace mentions.

Dependency rules map a check to a level (:error or :warning), or to nil to
turn it off:

- :stable-dependencies flags a dependency on a less stable brick (the
  Stable Dependencies Principle).
- :new-dependencies flags a dependency that is not in the base, when
  comparing with one (applied by the baseline component).
- :mutable-state flags top-level atoms, refs, agents, volatiles, and
  dynamic vars, and alter-var-root calls, in components.
- :broad-catch flags catch clauses for Exception, RuntimeException,
  Throwable, or Object in components.
- :test-boundary flags a require, in a brick's tests, of another brick's
  namespace other than its interface.

Five rules take settings as a map with :level:

- :connascence-of-position {:max n} flags interface functions that other
  bricks call with more than n positional parameters.
- :duplicate-code {:min-forms n} flags code of at least n forms that
  appears in more than one brick (connascence of algorithm).
- :merge-candidates {:max-size r} flags a component whose only dependent
  is another component, when its forms are at most r times the
  dependent's.
- :co-change {:since s :min-shared n :min-strength r
  :max-bricks-per-commit m} flags two bricks with no dependency path
  between them that changed together in at least n commits since s,
  and in at least r of the less changed brick's commits. Commits that
  touch more than m bricks don't count. check reads the commits from the
  analysis's :commits, each a set of changed paths, and skips the rule
  without them.
- :library-spread {:max-bricks n} flags each require of a library outside
  the workspace that more than n bricks require.

Library spread: the bricks that require each library outside the
workspace. A library wrapped by one brick can be replaced or upgraded in
one place; one spread across bricks, such as a database driver, means a
missing gateway component.

Map namespaces to Polylith interfaces.

Tests seen from the workspace: interface definitions no test mentions,
and tests that reach into another brick's implementation rather than
its interface.