the-custodian/docs/changes/CUST-WP-0080/receive-hook-operations.md

Initial forge receive-hook activation

Owner work: FORGE-WP-0006-T02, coordinated through RMGR-WP-0021-T03 and CUST-WP-0080 G07. The exact proposed action is receive-hook-proposal.json; its executor and artifact hashes are immutable for that trial. The standing build-mode authorization supplies the reversible-change authority; this is not an independent owner approval, autopilot promotion, or credential-isolation proof.

Composition and scope

The proposal enumerates 22 existing repositories, their eight original hook-file hashes, the exact running pod/image, and two admitted Linux executables. Only an additional pre-receive.d/10-custodian-secret-scan is retained. Generated Forgejo dispatchers and authorization hooks remain byte-for-byte unchanged. Tool storage is /data/security/receive-secret-scan/20261012-57a0642b6251, on the existing persistent data volume. No user-authored arbitrary hook facility is enabled.

Metadata reconciliation found 165 repositories; the other 143 are uncovered, not exempt. Actions enabled and branch-protection metadata do not prove required CI checks, credential scope, or frontend lifecycle enforcement.

Execution and rollback

From the Custodian checkout, default invocation performs read-only preflight:

python3 docs/changes/CUST-WP-0080/activate_receive_hooks.py \
  --proposal docs/changes/CUST-WP-0080/receive-hook-proposal.json \
  --receipt docs/evidence/2026-10-12-netkingdom-security/receive-hook-activation.json

--apply performs the exact mutation and writes its receipt; do not reapply to an already installed profile. On failure after hook writes, automatic rollback removes only the known added hook files and verifies the original inventory. --rollback performs that same removal explicitly and does not require temporary build artifacts. It retains the admitted tools as inert files. Explicit rollback still verifies the pinned live target and health; if the pod has changed or health is failing, the abort owner must review the current target before recovery. Never edit the original proposal to disguise a changed execution revision.

Unknown hook modifications cause rollback refusal rather than deletion. Inspect the receipt and exact path hashes; preserve evidence and resolve the concurrent change with the forge owner. Temporary staging cleanup requires a matching owner marker. No existing repository data, config, ref, account, or credential is removed by ordinary rollback.

Verification boundaries

The isolated native probe tests clean acceptance, intermediate-history detection, scanner unavailability, quarantine discard and recovery using the exact deployed image and binaries. Its Forgejo authorization hook is stubbed and the receipt explicitly says so.

Activation uses the actual SSH transport and existing authorization hooks. A separate, directly tested temporary hook vetoes the exact synthetic probe ref on all 22 targets. Both clean and disposable-secret probes must therefore fail the push, while the scanner must separately report clean and blocked. Ref absence and quarantined-commit absence are checked. The temporary veto is removed only after all probes pass. No synthetic key is valid for authentication or retained in Git. Native probe logs and fixture material are not published.

These forced rejections alone do not prove normal clean acceptance. The next ordinary authorized source push supplies that evidence, scoped to its repository and commit. HTTP pushes, frontend edits/merges/imports, restart/hook regeneration, new-repository reconciliation, historical/LFS/log/artifact coverage, and governed finding-to-response acceptance remain open in the owner plan.

The installer rehearsal uses local stand-ins for transport and scanner, proving installation/rollback behavior only. It covers partial installation recovery, missing build artifacts during rollback, executable mode checks, and preservation of unknown changes. It is not a substitute for either native receipt.