Publish a code of conduct naming the two routes a report takes (#107)

[iderex]

The issue this belongs to

Closes #107

What changed

CODE_OF_CONDUCT.md arrives at the root, and it names a route that answers.

That was the whole of what kept this issue open. The templates half landed at
f8ee6102 and is recorded on the issue as finished; what was left was a
document nobody could write, because a code of conduct with no route to a person
is useless at the moment somebody needs it, and which route this repository
publishes was entry 5 of #1. That entry was answered on 2026-09-04 - GitHub's own
channels, no mailbox on this board or any other - so the document can now name a
destination instead of promising one.

The file names the private report form on this repository first and a message to
the account that holds the repository second, in that order, which is the shape
the answer gives. It reads the setting the first route depends on rather than
asserting it, and it says plainly that the reading needs administrative access
and is therefore not one a reader of this board can run. Beside that it states
what is expected, what is not acceptable, what happens after a report arrives,
and exactly which responses are available, which is a short list and shorter than
a reader would assume.

Three things it says about itself, because each of them is the kind of thing a
document like this usually implies the opposite of:

• One person holds it. A report about my own behaviour comes to me, there is no
  appeal and no second reader, and GitHub's own abuse route is named because it
  is the one that does not go through me.
• No check reads it and none could. Every gate leg here judges bytes in the tree,
  and how somebody spoke to somebody else is not a byte in the tree.
• It is not the Contributor Covenant. That document's enforcement section
  describes a body of people, a ladder of consequences and a review of appeals,
  none of which exists here, and publishing a ladder nobody climbs would describe
  an apparatus this repository does not have.

SECURITY.md carries an earlier reading of the same repository setting answering
false and says in its own words that the destination was shut on the day it was
read. The new file records that disagreement and which of the two readings is the
later one, rather than leaving a reader to find the two documents contradicting
each other. I have not edited SECURITY.md: that file is #24's and this change
does not reach into it.

.github/ISSUE_TEMPLATE/config.yml gave "not decided" as its reason for carrying
no contact link, and the same answer took that reason away. The comment now
records the decision and gives the reason that survives it: a link there would be
a second copy of a route, and the copy is what drifts and sends somebody to the
older of the two. The setting itself is unchanged.

What failure it prevents

A stranger arriving here with a conduct problem and finding nothing at all, which
is the state before this change and is measured below, or finding a document that
describes a reporting apparatus which does not exist. The second is the worse
half: a promise of an appeal, a body of readers, or a response time that this
repository cannot hold reads as coverage to somebody deciding whether to report,
and they find out it was not at the moment they most need it to be true.

The failure has already happened once in a neighbouring shape on this board.
SECURITY.md was written naming a private route while the setting behind it was
off, and it had to carry a paragraph saying so. This document reads the setting
first.

The means

Markdown at the repository root, which is not a free choice: the row this issue's
done condition reads is populated by GitHub from a file in one of three known
locations, and prose is what a code of conduct is. It adds no language, no
runtime and no dependency, and it is judged by the document checks this tree
already runs, which is the fourth question the means check asks and the reason
nothing else was weighed.

Evidence

Run at the commit being pushed.

git rev-parse HEAD
0a6dcc70b20aa25f9bfe4502dc07eb464019b189
git diff --name-only origin/main...HEAD
.github/ISSUE_TEMPLATE/config.yml
CODE_OF_CONDUCT.md

Nothing stood behind the row before this change, and the file is tracked now:

git ls-tree -r --name-only origin/main | grep -c CODE_OF_CONDUCT ; echo "exit=$?"
0
exit=1
git ls-files | grep -c CODE_OF_CONDUCT
1

The route the document names answers:

gh api repos/Flowfin/core/private-vulnerability-reporting
{"enabled":true}

That endpoint needs administrative access to this repository, so it is not a
command a reader of this board can run, and the document says so where it pastes
it.

The document checks:

bash .github/doc-paths/doc-paths.sh selftest ; echo "exit=$?"
exit=0
bash .github/doc-paths/doc-paths.sh check | tail -1
Every path these documents name resolves against the tracked set.
bash .github/invariants/invariants.sh check > /dev/null ; echo "exit=$?"
exit=0
bash .github/format/format.sh check > /dev/null ; echo "exit=$?"
exit=0

The two commands CONTRIBUTING.md names, both green on this commit:

cargo build --locked --all-targets
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 13.79s
cargo test --locked
test result: ok. 125 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

Neither of those touches this change: no Rust source moved, and they are run
because the document says to run them before pushing, not because they judge a
Markdown file.

What this does not cover

The done condition is not verified by this pull request and cannot be. The
command it names reads the repository rather than a tree, so the code_of_conduct
row still answers missing at this commit and will go on answering missing
until the file is on main:

gh api repos/Flowfin/core/community/profile --jq '.files | to_entries[] | .key + "\t" + (if .value == null then "missing" else "present" end)'
code_of_conduct	missing
code_of_conduct_file	missing
contributing	present
issue_template	missing
license	present
pull_request_template	present
readme	present

I will re-run it after the merge and write the reading into the issue. If the row
does not move, this change has not met its condition, whatever the diff says.

The issue_template row above will not move either, and this change does not
try. That is recorded on the issue already, with the readings behind it: the
field reports one legacy path, a directory of templates can never satisfy it, and
the authoritative reading is the GraphQL issueTemplates field. I am not
restating that argument here beyond the sentence it takes to say why one of the
two rows in the condition is left where it is.

Whether anybody would actually be well served by either route is not
measurable here. No report has been sent through them, the first has never been
used on this repository, and this pull request establishes only that the door
exists and answers, not that it is a good door.

Nothing in this tree refuses a violation of the file, and the file says so
about itself. That is not a gap I have left for somebody to close: there is
nothing in a tree for such a check to read.

Text unchanged in SECURITY.md. Its reading of the private reporting setting
is older than the one in the new document and answers the other way. I have said
which is later and left the file to the issue that owns it.

Who has read it

Nobody but me. There is no second reader on this board tonight, so the evidence
above stands in place of a review rather than beside one.