considered

README

Considered

Considered is a CLI that lets you set codebase standards (e.g. file line counts) and explicitly document exceptions.

It collects metrics from one or more providers, evaluates them against declared standards, and reports violations. Intentional departures are documented as variances: reviewed, visible exceptions with a reason.

The goal is not merely to enforce limits. It is to make architectural decisions explicit and preserve the rationale behind unusual structures.

Quick Start

Install the published release with Homebrew:

brew install --cask quitepicky/tap/considered

This installs both considered and considered-scc. Release archives are also available from GitHub Releases. WinGet support is configured as QuitePicky.Considered; it becomes available after the first manifest submission is accepted into the community repository.

Build from source

Requires Go 1.26+. This repository vendors scc as a git submodule, so clone with submodules:

git clone --recurse-submodules https://github.com/quitepicky/considered.git
cd considered
go build -o bin/considered ./cmd/considered
go build -o bin/considered-scc ./cmd/considered-scc

Put both binaries on your PATH, then initialize and check a repository:

considered init
considered check

Documentation

The full guide is at considered.quitepicky.dev. The Astro documentation source lives under docs/:

cd docs
npm install
npm run dev

The docs cover configuration, variances, exclusions, providers, CI output, and the CLI reference.

Releases

GitHub Releases are published from version tags:

git tag v0.1.1
git push origin v0.1.1

GoReleaser builds considered and considered-scc together for Linux, macOS, and Windows on amd64 and arm64. Each release includes platform archives plus checksums.txt. Stable releases update the Quite Picky Homebrew tap and submit WinGet manifests. See RELEASING.md for credentials, validation, and the Garden release workflow.

Design Principles

1. Standards should be easy to declare.
2. Violations should remain visible.
3. Variances require rationale and classification.
4. Variances remain visible.
5. Metrics are provider-agnostic.
6. Configuration should be human-readable and double as architectural documentation.
7. Exact subject matching is preferred over complex selector systems.
8. Repository knowledge should be preserved alongside policy.