Contributing to Lemonfiber

Thank you for wanting to contribute. This project works a little differently from most, and understanding the one core rule up front will save you a round-trip.

You don’t have to write code

The most valuable contributions often aren’t code:

• Try it and report what broke — clear bug reports save everyone time.
• Fix or improve docs — spot something unclear and fix it; a docs PR counts.
• Design & UX feedback — on the web UI or the brand.
• Help others on Discord, and shape the roadmap.
• Spread the word — a star or a mention helps a young project.

Non-code changes still follow the one rule below (they cite a spec identifier, or GOV-R12 for routine docs), but they’re just as welcome as code. If you’re not sure how to file something, ask on Discord — we’ll help.

The one rule

The spec is canonical. Every change cites something in it that already exists.

A specification that trails its implementation is useless — so here the spec leads. Every commit to an implementation repo — every repository in the org besides spec, this one included — references a spec identifier (a requirement like A2-R4, an ADR-0006, or a governance rule like GOV-R12), and that identifier must already be merged in the spec.

Which case are you in?

Implementing something already specified — find the requirement, cite it:

feat: health-gate service startup

Spec: B2-R1, B2-R2

Put the same IDs in your PR body. That’s it.

Changing how the product behaves — open a small PR against spec first. Usually one requirement row and a short paragraph. Once it merges, cite the new ID in your implementation PR.

Routine maintenance (dependencies, formatting, CI) — cite GOV-R12.

Full guide

The complete contributor guide lives in the spec: 50-governance/contributing.md.

It covers finding the right identifier, the change lifecycle, what the CI checks, and what to do if your PR is closed (it’s sequenced, not rejected — reopening is one click).

Turn the hooks on, once per clone

The citation above is one of four things checked about every commit message. The other three are a conventional subject, a DCO sign-off, and no credit to the tool that wrote it. Each is a separate check that speaks after a push and a red run.

Every repository here carries a commit-msg hook that says all four before any of that, with the literal line to add. It is off until a clone turns it on:

git config core.hooksPath .githooks

Or run whichever of just ci, npm install or composer install that repository has — each sets it, because the setting is per-clone local config and no commit can carry it.

What the four rules are, and which requirement each serves: 50-governance/contributing.md.

Before you open a PR

• The hooks are on, so the commit message is already the one CI will accept.
• Your change cites a spec identifier, in a commit trailer and the PR body.
• If it changed behaviour, the spec PR merged first.
• Tests pass, and the definition of done is met.
• No requirement IDs in code comments — they go in commits and PRs only.

Questions

Ask in Discord, or open an issue. If you’re unsure which repo an issue belongs in, file it anywhere — routing is our job, not yours.