Contributing

Use the Codefloe repository for bug reports and pull requests. Report vulnerabilities through the security policy.

Discuss large features, schema or federation changes, and new dependencies first. A patch should explain the problem, resulting behavior, checks run, and any effects on stored data, configuration, security, or interoperability. Sign commits and include the DCO sign-off (git commit -S -s) and update Unreleased for user-visible changes.

See development for setup and checks.

Documentation

Describe the task the reader can perform and the controls or commands needed. Keep prerequisites, limitations, and recovery instructions with that task.

• Check user-facing claims in the running interface. A route or form in the source does not prove that a user can reach or complete it.
• Distinguish local authoring, API access, remote object handling, and test coverage.
• Name compatibility targets separately from verified behavior.
• Use the actual control labels. Check commands against help and configuration against the parser for the documented release.
• Keep one detailed explanation per topic and link to it. Avoid promotional claims, unrelated comparisons, repeated caveats, and lists of internal modules in user instructions.
• Keep investigation narratives out of task guides. Track pending public-launch work in Before going public.
• If clear instructions require a code, packaging, or publishing change, discuss that issue before changing the implementation or documenting a workaround.

Check links and syntax for prose and example edits. ./dev docs-check also builds the application and checks runtime documentation. If CLI help changes, regenerate it with ./dev docs-generate. Shell examples in docs/examples/ must pass syntax checking and ShellCheck; deployment TOML examples must pass configuration tests.