Configuration

simplicity.json reference

Configuration is optional on the first run and strict once you add it. Place simplicity.json beside the solution, override only what you need, and let unsupported values fail fast instead of silently changing the contract.

Full shape

The current schema covers TCA inputs and filter thresholds.

{
  "tca": {
    "teamSize": 8,
    "averageEngineerMonthlySalaryUsd": 15000,
    "estimatedMonthlyIncidentCount": 4,
    "onCallHourlyRateUsd": 150,
    "attritionCoefficientPercent": 15
  },
  "filters": {
    "primaryPathRatioTarget": 0.6,
    "prematureAbstractionRatioTarget": 0.25,
    "maxMethodComplexity": 5,
    "maxOnboardingHours": 40,
    "passingScore": 0.7
  }
}

Behavior rules

The loader is permissive about missing files and strict about bad files. That is an intentional boundary.

  • Missing simplicity.json produces a warning and the CLI continues with built-in defaults.
  • Partial files are allowed; omitted values fall back to defaults.
  • Unsupported properties and out-of-range values fail fast instead of being ignored.
  • The file is loaded from the solution directory only, not by walking parent folders.

Practical minimal override

Override only the thresholds you actually want the team to own.

{
  "filters": {
    "primaryPathRatioTarget": 0.75,
    "maxMethodComplexity": 4
  }
}

If a threshold changes, treat it like a policy decision. Otherwise you are just moving the goalposts to make the output quieter.

Where configuration shows up

Different commands consume the same file in different ways.

budget

Uses filter thresholds directly to render the four budget dimensions.

report

Uses the same thresholds in the HTML budget section and related guidance.

watch

Reloads the file on every pass so threshold changes show up without restarting the process.

TCA inputs

Feed cost-of-complexity calculations for CLI/report flows; library consumers can pass inputs directly instead.