A conduct report has a route, and the first release has a changelog

[iderex]

Closes #10
Closes #44

Two issues in one pull request, both landing documents and nothing else. They
share a branch because separate landings of document-only changes move the
mainline under each other and the queue stops converging. Each is one commit, so
the two topics are separable in the history.

What this changes

#10 - a conduct report has a route, and the security policy stops sending
reporters the wrong way.

CODE_OF_CONDUCT.md is new. The routes are the two decided on #10 on
2026-09-04, in that order: the private report form on this repository, then a
message through GitHub to the account that holds it. No mailbox is named. The
document says what I can actually do about a report, that one person holds it
with no second reader and no appeal, and that nothing in this repository
enforces a word of it.

SECURITY.md carried three readings that had stopped reproducing.

• It said the private form does not answer, quoting {"enabled":false} from
  2026-08-19, and offered a public issue as the honest alternative until it
  opened. The form is open. The fallback is gone and the file now says a report
  sent anywhere else is not received.
• It said nothing is published as a binary, quoting two empty lists. There is a
  release and a tag. A published artefact that does not match its checksum or
  its signature is now named as a report I want, and the covered set names the
  most recent release beside the default branch.
• It said thirteen files in .github/workflows. There are fifteen, and I re-ran
  the four claims that paragraph makes over all of them.

#44 - there is a changelog, because there is now a release to write an entry
for.

CHANGELOG.md is new, with an entry for v0.1.0 and the compatibility position
in front of it: no promise of stability, and a change not made silently. A
change invalidating records already on the default branch is announced in the
entry for the release carrying it; the record under docs/decisions/ is still
where such a change is decided; the exit codes are the one part of the runner
anything may key on.

docs/operator-guide.md said in the present tense that there is no changelog
and no release for one to carry an entry for. That is the sentence #44 says
moves into the changelog when one lands, and this is it moving.

No path leaves the tree in this change.

What failure it prevents

Somebody with a conduct problem on a public board had one visible route, which
was an issue that names the person it is about to everybody before anybody has
read it. That is the outcome SECURITY.md exists to prevent for a
vulnerability, and it was unprevented one file over.

Beside it, SECURITY.md was telling a reporter that the private form does not
answer and that a public issue is the honest alternative, while the form was
open. It was also telling them there is no published artefact to have been
tampered with, the day after this board published a signed release of six
binaries. A
security policy that is wrong about its own route sends the report to the one
place it was written to keep it out of.

For the changelog: this board is allowed to break its own tool between versions,
and somebody is now running a version of it. Without a changelog the only answer
to what changed is a reader comparing two commits, and a format change that
invalidated their records would reach them as a broken run rather than as a
sentence.

What was run

At 205201a97690df0326d61cbbe969d949345d136e, the head being pushed, on
Windows.

$ go build ./cmd/... ./internal/... && go vet ./cmd/... ./internal/...
(no output)

$ gofmt -l cmd internal
(no output, which is the passing result)

$ go test -count=1 ./cmd/... ./internal/...
ok  github.com/Flowfin/lab/cmd/bom
ok  github.com/Flowfin/lab/cmd/contexts
ok  github.com/Flowfin/lab/cmd/lab
ok  github.com/Flowfin/lab/cmd/notices
ok  github.com/Flowfin/lab/cmd/pullrequest
ok  github.com/Flowfin/lab/internal/bom
ok  github.com/Flowfin/lab/internal/check
ok  github.com/Flowfin/lab/internal/contexts
ok  github.com/Flowfin/lab/internal/hardware
ok  github.com/Flowfin/lab/internal/invariants
ok  github.com/Flowfin/lab/internal/notices
ok  github.com/Flowfin/lab/internal/prose
ok  github.com/Flowfin/lab/internal/pullrequest

$ go run ./cmd/lab check .
examined .
1 experiment directory walked, 1 record read
27 decision records read
0 refused

The -v run was made as well and is not pasted, because its output is the whole
suite. What it prints that the summary above does not is the line saying the
integration-hardware harness was not asked for and what asking would cost, and
that leg was not asked for here.

The pointer this change adds is guarded, and I proved the guard bites rather
than reading the code for it. With CHANGELOG.md moved out of the tree:

$ go test ./internal/invariants -run TestThisRepositorySatisfiesTheInvariants -count=1
--- FAIL: TestThisRepositorySatisfiesTheInvariants (0.17s)
    ..\..\docs\operator-guide.md: it names CHANGELOG.md, which is not in this
    tree (document-names-a-path-that-does-not-resolve)
FAIL

and ok with the file back. The separators in that path are the host's.

lab check . stays green over the same missing file, which I checked before
claiming the route: the path leg is a repository invariant rather than a record
check.

The readings the two documents now quote, taken at the moment they were
written into them rather than recalled:

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

$ gh api repos/Flowfin/lab/releases --jq 'length'
1
$ gh api repos/Flowfin/lab/tags --jq 'length'
1

$ git ls-tree --name-only origin/main .github/workflows/ | wc -l
15
$ git grep -n -E 'pull_request_target|workflow_run' origin/main -- .github/workflows/
(no output, exit 1)
$ git grep -n -E 'uses: .*@(v[0-9]|main|master)' origin/main -- .github/workflows/
(no output, exit 1)

Fourteen of the fifteen check out the repository and every one of those passes
persist-credentials: false; the fifteenth, smoke.yml, checks nothing out.
Every one of the fifteen declares permissions: {} or a read-only scope at the
top level, read file by file rather than sampled.

The v0.1.0 output quoted in the changelog is the published asset, not a
build made here:

$ sha256sum --check --ignore-missing SHA256SUMS
lab_v0.1.0_windows_amd64.exe: OK

$ ssh-keygen -Y verify -f allowed-signers -I iderex -n file -s SHA256SUMS.sig < SHA256SUMS
Good "file" signature for iderex with ED25519 key SHA256:Kl42N4iJnL6folkHvxySv75mNc0N0QNLF8bb2iU0SZ0

$ ./lab_v0.1.0_windows_amd64.exe version
lab v0.1.0
built from commit ed16621442c00a3ad47edd918d68edf68341753e, 2026-09-01T09:14:10Z

The allowed-signers file was built from
https://api.github.com/users/iderex/ssh_signing_keys, which is the route the
release notes give, rather than from a key shipped beside the signature.

What this does not do

No second reader read this. The rule is that nothing reaches the mainline
that only its own author has read, and this change breaks it: there is nobody
else on this board tonight. What stands in place of a reader is the evidence
above, which is weaker than a person and is not offered as equivalent. The
sentence stays as it is if somebody reads the change later.

The community-standards clause of #10 is not readable until this merges.
gh api repos/Flowfin/lab/community/profile --jq '.files.code_of_conduct'
answers null while the file is on a branch. I read the same field across every
repository in this organisation: eight answer with a key rather than null, and
six of those eight carry a document the platform classifies as other rather
than a recognised text, so a custom document is enough for the page to list one.
The clause is expected to pass on merge rather than proved to.

Nothing enforces the conduct document, which it says about itself. Every leg
of the run judges bytes in the tree and how somebody spoke to somebody else is
not one.

No check reads the changelog. Nothing refuses a release published without an
entry, and nothing compares the entries here against the releases on the
platform. What holds the link from docs/operator-guide.md is the path leg
above; the content of an entry is held by nothing.

The private form was read with administrative access. A reader of this board
cannot run
gh api repos/Flowfin/lab/private-vulnerability-reporting, and both documents
say so where they quote it. What a reader can do is open the address and see
whether the form is there.