docs(spec): B4 resolved — the audit status context cannot match GitHub

[ProtocolWarden]

The spec's last open item, resolved by actually running it. Forgejo Actions is live: runner 6.3.1 registered against the instance, probe workflow executed end to end (pulled node:20-bookworm, success in 91s).

B4's premise was wrong, and sharper than "inconvenient"

B4 said audit "must be reproduced under an identical context name, or every PR blocks forever". The identical name is not achievable.

GitHub uses the job id, so OC's required context is the bare string audit. Forgejo composes:

<workflow name:> / <run-name> (<event>)

…and with no run-name:, the middle segment is the commit message. The first probe produced:

audit.yml / ci: probe the status context name (push)

A required status check is a fixed string. A context carrying the commit message changes on every push — so the default configuration isn't mismatched, it's unsatisfiable in principle. No amount of renaming on the GitHub side fixes it.

run-name: audit pins it:

custodian-audit / audit (push)

Verified stable by re-running under a deliberately different commit message.

Second finding: both events fire on a PR head

custodian-audit / audit (pull_request)  -> success
custodian-audit / audit (push)          -> pending

The GitHub workflow triggers on both, so on Forgejo that does the work twice and leaves a second context outstanding for any gate requiring "nothing incomplete". Trigger on pull_request only.

Cutover configuration, now concrete

• workflow: name: custodian-audit, run-name: audit, on: pull_request
• branch protection status_check_contexts: custodian-audit / audit (pull_request)
• apply_to_admins: true (the earlier live finding)

Any checklist saying "use the same name" is wrong.

Bonus: #517 validated against real data

The probe exercised ForgejoPRClient on actual Forgejo statuses rather than fixtures:

failed:     []
incomplete: ['custodian-audit / audit (push)']
completed:  ['custodian-audit / audit (pull_request)']

The endpoint returned a three-entry posting history (pending, pending, success) for one job, and the latest-per-context dedupe resolved it exactly as designed.

Also included

deploy/forgejo/README.md records the runner setup so it's reproducible — including why it joins the docker group rather than running as root, and that either way it grants control of the Docker daemon, which is root-equivalent on the host.

(The link checker reports 1 broken link in worktrees only — docs/backends/aider_local.md points at a sibling repo worktrees don't have; broken: 0 from a real checkout.)

🤖 Generated with Claude Code