Public memory references the signing guard without documenting it #26

New issue

Open

opened 2026-07-27 18:26:09 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-07-27 18:26:09 +01:00

Contributor

Public git-workflow.md warns that the branch-protection and signing guards go silent inside a linked worktree, but nothing in public memory says what the signing guard is, which branches it covers, or how to satisfy it. A public-only agent meets the term for the first time in a warning about it failing.

Primary goals:

Document the mechanism — protected-refs-policy requires the tip commit to be GPG-signed when pushing a branch listed in ~/.config/git/signing-required-branches.
Give the satisfying command — git merge -S --no-ff <branch> signs the merge commit, which is what a signing-required default branch needs.
State the bypass posture — git push --no-verify exists but is a deliberate human act, never a mode an agent adopts, per architecture.md principle 4.

Current state

git-workflow.md "Worktrees and Concurrent Agents" refers to the signing guard being silent in a worktree. A case-insensitive search for "sign" across public memory otherwise returns only "signal" and "design", so the guard itself is undocumented. The mechanism is public: allod/tools git-hooks/protected-refs-policy is_signing_required_branch (:35) reads signing-required-branches with the same $HOME-relative key as protected-branches, which is why allod/tools#112 also determines whether the guard works from a worktree at all.

This surfaced while classifying private memory for the public/private split. The signing convention sat inside a private project's topic file, so classifying at file granularity kept the whole file private even though the mechanism half belongs in public memory. Worth noting as a method limit: a mixed file needs fact-level classification, not file-level.

Scope

In: a short signing section in public git-workflow.md. Out: any deployment's actual signing-required-branches contents, which are private data, and the identity-resolution fix tracked in allod/tools#112.

Public `git-workflow.md` warns that the branch-protection and signing guards go silent inside a linked worktree, but nothing in public memory says what the signing guard is, which branches it covers, or how to satisfy it. A public-only agent meets the term for the first time in a warning about it failing. Primary goals: - **Document the mechanism** — `protected-refs-policy` requires the tip commit to be GPG-signed when pushing a branch listed in `~/.config/git/signing-required-branches`. - **Give the satisfying command** — `git merge -S --no-ff <branch>` signs the merge commit, which is what a signing-required default branch needs. - **State the bypass posture** — `git push --no-verify` exists but is a deliberate human act, never a mode an agent adopts, per `architecture.md` principle 4. ### Current state `git-workflow.md` "Worktrees and Concurrent Agents" refers to the signing guard being silent in a worktree. A case-insensitive search for "sign" across public memory otherwise returns only "signal" and "design", so the guard itself is undocumented. The mechanism is public: `allod/tools` `git-hooks/protected-refs-policy` `is_signing_required_branch` (`:35`) reads `signing-required-branches` with the same `$HOME`-relative key as `protected-branches`, which is why allod/tools#112 also determines whether the guard works from a worktree at all. This surfaced while classifying private memory for the public/private split. The signing convention sat inside a private project's topic file, so classifying at file granularity kept the whole file private even though the mechanism half belongs in public memory. Worth noting as a method limit: a mixed file needs fact-level classification, not file-level. ### Scope In: a short signing section in public `git-workflow.md`. Out: any deployment's actual `signing-required-branches` contents, which are private data, and the identity-resolution fix tracked in allod/tools#112.