Once it’s merged, open your implementation PR citing the new ID.
The spec PR is usually small — one row in a requirements table and a paragraph
explaining the behaviour. It’s not an essay.
Why the extra step: it separates “should the product do this?” from
“is this code good?”. Reviewed together, working code tends to win the first
question by default, because working code is persuasive. Reviewed apart, the
design gets judged on its merits.
“I’m bumping a dependency / fixing a typo / touching CI”
git commit -s adds a DCO Signed-off-by line — your assertion that you
have the right to submit the work under the repo’s licence. A dco check
enforces it. See dco.md.
Signed commits (SSH or GPG) prove who you are. main requires them.
git config commit.gpgsign true once, and always commit with -s, and both are
handled. Your contribution ships under the repo’s licence (Hippocratic 3.0 for
code) — inbound equals outbound, no CLA.
Don’t put requirement IDs in code comments. Ever. Not as a breadcrumb, not
“just this once”. Provenance in a comment is worthless to the next reader and
rots the moment the requirement is superseded. IDs go in commits and PRs; code
links to lemonfiber/.docs/, and those pages cite the spec.
Don’t cite a Draft requirement. Draft means undecided. If you’re implementing
it, it should be Accepted first.
Don’t write the spec change to match code you’ve already written. It’s
technically possible and it inverts the whole point. If implementation taught you
something, say so in the spec PR — that’s valuable and welcome.
Thanks for this — the change itself looks fine, and it isn’t rejected.
This org keeps its specification canonical: every change references something
in lemonfiber/spec that already exists
there. It stops the spec drifting behind the code, which is the failure mode
that makes specifications useless.
Your PR doesn’t cite a spec identifier yet. To proceed:
If this implements something already specified — find the requirement,
add a trailer to your commit, and reopen:
Spec: A2-R4
If this changes product behaviour — open a small PR against the spec repo
first. Usually one requirement row and a short paragraph. Once it merges, cite
the new ID here and reopen.
If this is routine maintenance (dependencies, formatting, CI) — cite
GOV-R12 and reopen.
Full guide: contributing.
Happy to help find the right identifier — just ask here.
Reopening costs one click. Nothing is lost, and no work is thrown away.
Say so — in an issue on the spec repo, or in the PR. The rule is written down
precisely so it can be argued with, and changing it is itself a spec PR
(GOV-R11).
What isn’t available is quietly ignoring it, because then the rule stops meaning
anything and the drift it prevents starts happening again.
Ask on Discord, or open an issue. If you’re not
sure which repo an issue belongs in, file it anywhere — routing is a maintainer’s
job rather than a reporter’s (GOV-R25).