Project type examples

The project.type field accepts one of node, python, go, rust, java, or unknown. The schema treats every type identically, but FlowForge’s defaults aim for a “reasonable everywhere” middle ground — for any specific ecosystem, a small amount of tuning produces a config that feels native to that language community.

This page collects four ready-to-use starter configurations, one per language. Every example below is a complete .flowforge/config.yml and is valid against the schema. Drop the file in your project’s .flowforge/ directory, replace name and repository with your own values, and you are done.

Node / TypeScript

# .flowforge/config.yml — Node / TypeScript project
version: '3.0'

project:
  name: my-node-app
  type: node

tracking:
  provider: github
  repository: my-org/my-node-app
  syncEnabled: true

rules:
  extends: []
  overrides:
    # JSDoc on every public export keeps DefinitelyTyped happy.
    jsdoc-required:
      severity: error
    # Keep release branches off the floor.
    branch-protection:
      severity: error
      options:
        protectedBranches:
          - release/*

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

Why these choices. The Node ecosystem leans on Conventional Commits for changelog generation (conventional-changelog, semantic-release, changesets), so commitFormat: conventional matches established tooling. Promoting jsdoc-required to error is appropriate for libraries that publish .d.ts files; the default warning is fine for application code that does not publish a type surface.

Python

# .flowforge/config.yml — Python project
version: '3.0'

project:
  name: my-python-app
  type: python

tracking:
  provider: github
  repository: my-org/my-python-app
  syncEnabled: true

rules:
  extends: []
  overrides:
    # Python doesn't use JSDoc — defer to ruff/pydocstyle for docstrings.
    jsdoc-required:
      severity: off
    # Python doesn't write console.log; the rule only matches JS/TS files anyway.
    no-console-log:
      severity: off
    branch-protection:
      severity: error

standards:
  # Coverage targets vary widely in Python; 75% is a healthy starting line
  # while a project's test suite is still maturing.
  testCoverage: 75
  # Python files trend longer than TS files; 800 leaves room for module-level
  # docstrings and type stubs without inviting bloat.
  maxFileLines: 800
  # max-function-lines only inspects JS/TS files, so the value here is moot
  # for Python sources but kept at the project default for consistency.
  maxFunctionLines: 50
  commitFormat: conventional

Why these choices. The jsdoc-required and no-console-log rules target JavaScript and TypeScript files specifically and have nothing to do in a Python source tree. Turning them off explicitly avoids surprise in audit reports. Coverage starts a little lower than the universal default to acknowledge that Python projects often bootstrap with strong type-checked test seams that take time to grow into 80%; ratchet it back up as the suite matures.

Go

# .flowforge/config.yml — Go project
version: '3.0'

project:
  name: my-go-service
  type: go

tracking:
  provider: github
  repository: my-org/my-go-service
  syncEnabled: true

rules:
  extends: []
  overrides:
    # JSDoc and console.log rules don't apply to .go files.
    jsdoc-required:
      severity: off
    no-console-log:
      severity: off
    branch-protection:
      severity: error
      options:
        protectedBranches:
          - release/*
          - hotfix/*

standards:
  # Go's idiomatic style produces small, table-test-friendly files; 700 is fine.
  testCoverage: 80
  maxFileLines: 700
  # Go functions are commonly compact, but generated/protobuf files can push past
  # 50; raise the ceiling slightly to absorb them.
  maxFunctionLines: 60
  commitFormat: conventional

Why these choices. Go’s standard tooling (gofmt, go test, go vet) handles formatting and lint concerns natively, so FlowForge’s role is mainly to enforce project-wide invariants — branch protection, ticket references, commit format. Coverage at 80% matches Go community norms; go test -cover makes the metric easy to track. Function-length is bumped slightly to accommodate generated code (protobuf clients, gRPC stubs) without forcing project-wide overrides per file. Note: jsdoc-required and no-console-log do not currently scan .go files, so these overrides are documenting intent rather than silencing active warnings. Setting them explicitly future-proofs the config if rule scoping ever expands.

Rust

# .flowforge/config.yml — Rust project
version: '3.0'

project:
  name: my-rust-crate
  type: rust

tracking:
  provider: github
  repository: my-org/my-rust-crate
  syncEnabled: true

rules:
  extends: []
  overrides:
    # JSDoc/console.log rules target JS/TS files; no-op in Rust.
    jsdoc-required:
      severity: off
    no-console-log:
      severity: off
    branch-protection:
      severity: error
      options:
        protectedBranches:
          - release/*

standards:
  # Library crates benefit from a stricter coverage bar.
  testCoverage: 85
  # Rust files run long when traits, impls, and tests live together. 900 is a
  # comfortable ceiling for a typical crate module.
  maxFileLines: 900
  # max-function-lines only inspects JS/TS files; keep at default.
  maxFunctionLines: 50
  commitFormat: conventional

Why these choices. Rust idiom keeps trait declarations, implementations, and inline #[cfg(test)] modules in the same file, which legitimately pushes file length past the 700-line default. Bumping maxFileLines to 900 absorbs that pattern without inviting unbounded growth. Library crates aim for a higher coverage target than applications; 85% is a sensible starting line for a published crate. Conventional Commits is the default in the Rust ecosystem (used by cargo-release and release-plz). Note: jsdoc-required and no-console-log do not currently scan .rs files, so these overrides are documenting intent rather than silencing active warnings. Setting them explicitly future-proofs the config if rule scoping ever expands.

Java

# .flowforge/config.yml — Java project
version: '3.0'

project:
  name: my-java-service
  type: java

tracking:
  # GitHub is shown here; Linear and Jira are also common in Java enterprises.
  provider: github
  repository: my-org/my-java-service
  syncEnabled: true

rules:
  extends: []
  overrides:
    # Java uses Javadoc, not JSDoc; the rule doesn't currently scan .java files.
    jsdoc-required:
      severity: off
    # Java uses System.out.println; the rule doesn't currently scan .java files.
    no-console-log:
      severity: off
    branch-protection:
      severity: error
      options:
        protectedBranches:
          - release/*
          - hotfix/*

standards:
  # Industry-standard target for JUnit + JaCoCo stacks.
  testCoverage: 80
  # Java tends to produce somewhat longer files due to language verbosity;
  # 700 is still a healthy ceiling. Raise only if a domain genuinely demands it.
  maxFileLines: 700
  maxFunctionLines: 50
  commitFormat: conventional

Why these choices. Java’s canonical test stack is JUnit + JaCoCo, both of which make 80% coverage easy to track and a reasonable bar for a service or library. The 700-line ceiling holds up despite the language being more verbose than TS or Go — past it, most files have an extractable inner class or helper. jsdoc-required and no-console-log do not currently scan .java files, so the explicit off overrides document intent rather than silencing active warnings. Setting them explicitly future-proofs the config if rule scoping ever expands. Tracker provider is shown as github for consistency with the other starters; swap for linear or jira if your team lives there.

Unknown / polyglot

# .flowforge/config.yml — unknown / polyglot project
version: '3.0'

project:
  name: my-project

Why this is enough. When a project has no dominant ecosystem (a docs site, an infra-only repo, a polyglot monorepo), the right starter is the minimal valid config. The schema fills in project.type: unknown, tracking.provider: github, and the default standards — a sensible baseline for any repo. As the project’s shape clarifies, copy the relevant ecosystem starter from above and tune from there. Until then, this two-line config keeps FlowForge’s rule engine, ticket validation, and time tracking running without making assumptions the project hasn’t earned.

For ecosystem-tuned starters, see Node, Python, Go, Rust, or Java.

Customizing further

These starters are a beginning, not a contract. A few common follow-on tweaks:

Disable a rule entirely. Set severity: off on the rule under rules.overrides. See Built-in rules.
Add custom protected branches. Extend branch-protection.options.protectedBranches. See branch-protection.
Change tracker. Swap tracking.provider for linear, jira, notion, or local. See Tracking providers.
Raise or lower the coverage bar. Adjust standards.testCoverage between 0 and 100. See Standards.

For the field-by-field reference, see the config.yml schema.