Standards

The standards section of .flowforge/config.yml declares the four numeric thresholds FlowForge measures against: minimum test coverage, maximum file length, maximum function length, and commit-message format. Several built-in rules read directly from this section, so changes here propagate to those rules automatically. For the field shape, see the config.yml schema.

Section shape

standards:
  testCoverage: 80              # default
  maxFileLines: 700             # default
  maxFunctionLines: 50          # default
  commitFormat: conventional    # default

All four fields are optional. If the section is omitted entirely, every value above is applied as the default.

testCoverage

Attribute	Value
Type	number (0–100)
Default	80

The minimum test-coverage percentage FlowForge expects. Reports flag any package or module that comes in below this value.

The default of 80% reflects the FlowForge baseline: high enough to catch regressions on the happy path and the most common failure modes, low enough to leave room for genuinely hard-to-cover paths (process exits, race conditions, third-party-error propagation) without forcing artificial test code. Bump it up for libraries and critical infrastructure; bump it down briefly for exploratory spikes, and remember to put it back.

standards:
  testCoverage: 90   # raise the bar for a library project

maxFileLines

Attribute	Value
Type	positive integer
Default	700

The maximum number of lines a non-test source file may contain. The max-file-lines rule reads this value.

The default of 700 lines is a deliberate ceiling, not a target. Empirically, files that grow past this length almost always have at least one extractable submodule, and the size becomes a friction point in code review and navigation. Test files are exempt because table-driven tests and fixture-heavy specs legitimately get long without losing readability.

If you maintain a project where domain conventions push files larger (generated parsers, large schema files), raise the limit explicitly:

standards:
  maxFileLines: 1500   # acceptable for generated code

maxFunctionLines

Attribute	Value
Type	positive integer
Default	50

The maximum number of lines in a single function. The max-function-lines rule reads this value.

The default of 50 lines aligns with the rule of thumb that a function should fit on one screen and do one thing. Past this length most functions are doing more than one thing or have not yet had their early-exit logic factored out. The detector handles nested functions independently — a long outer function does not mask a long inner one — so raising the limit affects only the level you raise it at.

Lower the value for code bases that aim for more aggressive decomposition; raise it for handwritten parsers or state machines whose linear style is the right tool for the job:

standards:
  maxFunctionLines: 80

commitFormat

Attribute	Value
Type	enum
Default	conventional
Valid values	conventional, simple

The commit-message format FlowForge enforces:

• conventional — the Conventional Commits format (type(scope): description, with optional ! for breaking changes). The commit-message-format rule validates the subject line against this format.
• simple — the commit-message-format rule is skipped entirely. No format is enforced on the commit subject. Use this when your team has a pre-existing house style that conflicts with Conventional Commits, or when commit history is not used to drive changelogs.

The default is conventional because conventional commits are the lingua franca of release-note tooling and changelog generators. They impose a small upfront cost on each commit in exchange for free, accurate release notes and trivial automation downstream.

simple exists for projects where Conventional Commits would be overkill — small personal repos, throwaway prototypes, or teams that have an existing house style that conflicts with the conventional types.

standards:
  commitFormat: simple   # disable conventional-commits validation

Putting it together

A project that wants the FlowForge defaults explicitly pinned would set:

standards:
  testCoverage: 80
  maxFileLines: 700
  maxFunctionLines: 50
  commitFormat: conventional

A library with stricter expectations might set:

standards:
  testCoverage: 95
  maxFileLines: 500
  maxFunctionLines: 40
  commitFormat: conventional

A throwaway prototype that wants the rules engine on but the bars relaxed might set:

standards:
  testCoverage: 50
  maxFileLines: 1200
  maxFunctionLines: 100
  commitFormat: simple

For ecosystem-tuned starters, see Project type examples.

See also

• config.yml schema — top-level field reference.
• Built-in rules — full catalog, including the rules that read from standards.