Constant PREPARE_COMMIT_MSG_HOOK 

pub const PREPARE_COMMIT_MSG_HOOK: &str = r#"#!/bin/sh
# auths prepare-commit-msg hook v2 — managed by `auths init`, checked by
# `auths doctor`. Injects the Auths-Id / Auths-Device trailers so `auths verify`
# can replay the signer's KEL, and repairs a missing/untracked .auths/roots trust
# pin (the committed trust declaration teammates and CI inherit).
# Chains to the repo's own hook when one exists.

MSG_FILE="$1"
AUTHS_HOME="${AUTHS_REPO:-$HOME/.auths}"
TRAILERS="$AUTHS_HOME/commit-trailers"

if [ -f "$TRAILERS" ]; then
    TOPLEVEL="$(git rev-parse --show-toplevel 2>/dev/null)"
    if [ -n "$TOPLEVEL" ] && [ -f "$AUTHS_HOME/root-pin" ]; then
        PIN="$TOPLEVEL/.auths/roots"
        [ -e "$PIN" ] || {
            mkdir -p "$TOPLEVEL/.auths" && cp "$AUTHS_HOME/root-pin" "$PIN"
        }
        # Stage only when git isn't tracking it yet. This lands in the NEXT commit:
        # git snapshotted the index before this hook ran.
        if [ -e "$PIN" ] && ! git ls-files --error-unmatch -- "$PIN" >/dev/null 2>&1; then
            git add -- "$PIN" >/dev/null 2>&1 &&
                echo "auths: staged .auths/roots — your trust pin lands in your next commit" >&2
        fi
    fi
    while IFS= read -r trailer; do
        case "$trailer" in
        '' | '#'*) ;;
        *) git interpret-trailers --in-place --if-exists replace --trailer "$trailer" "$MSG_FILE" ;;
        esac
    done <"$TRAILERS"
fi

REPO_HOOK="$(git rev-parse --git-dir 2>/dev/null)/hooks/prepare-commit-msg"
if [ -x "$REPO_HOOK" ]; then
    exec "$REPO_HOOK" "$@"
fi
exit 0
"#;

The managed prepare-commit-msg hook. Version-stamped so auths doctor can detect a stale install; bump the version when editing.

The pin block is a repair path only — auths init owns pinning and staging via roots::pin_root_in_repo. It exists for repos entered after init ran elsewhere. Two constraints shape it, both learned the hard way:

1. It keys off tracked-ness, not existence. The previous version skipped when .auths/roots merely existed — which auths init had just created — so the pin was never staged and never travelled.
2. A git add here lands in the next commit, not this one: git has already snapshotted the index by the time prepare-commit-msg runs. The message says so rather than claiming otherwise.