gh prose examples carry no attribution sign-off, and --body-file paths must be literal (a shell variable is invisible to the hook)

[dmccoystephenson]

The gap

Two template rules are in direct conflict, and the combination breaks the first prose gh call of every cycle in every instance that has an attribution hook installed.

Half one — the examples carry no sign-off. Every gh issue create / gh pr create / gh pr comment example in the template composes a body with no attribution sign-off. Repositories with an attribution hook reject those calls outright, so the first prose call of a cycle fails and the loop has to rediscover the requirement each time.

Reported independently by at least 8 instances: apex-dev-loop#3, money-calculator-dev-loop#3, text-tool-dev-loop#3, viron-dev-loop#20, fishe-dev-loop#20, minecraft-nodes-dev-loop#1, roam-website-dev-loop#5, dans-spawn-system-dev-loop#6, py-env-lib-dev-loop#4.

Half two — the fix prescribed for a different problem defeats the sign-off. PR #93 replaced the heredoc body form with --body-file <path>, because some command classifiers reject $(...) command substitution outright. That fix is correct for the classifier problem, but the attribution hook inspects the command string, not the file the command points at. With --body-file, a body containing a perfectly correct sign-off is still rejected, because the hook cannot see it.

Evidence

Observed directly while opening a retrofit PR. --body-file was used with a body whose final line was exactly the required sign-off; the hook rejected the call. The same body inlined via --body "$(cat <<'EOF' ... EOF)" was accepted and the PR was created.

A second-order effect is worth recording: the hook rejects the entire Bash invocation, so chaining git work and the gh call in one && compound means none of it runs — including the commit and push. The git work and the gh call must be separate invocations, or a hook rejection silently discards the staging work too.

Suggested resolution

These cannot be resolved independently — a rule that says "use --body-file" and a rule that says "the sign-off must be in the body" are jointly unsatisfiable under a command-string-reading hook. Suggested template text:

• Keep --body-file as the default for bodies with no attribution requirement.
• Where the target repo has an attribution hook, use the inline heredoc form and place the sign-off as the last line of the body, accepting the command-substitution risk (a hook rejection is visible and recoverable; a silently-dropped sign-off is not).
• Detect rather than assume: if a gh prose call is rejected with an attribution message, re-issue it inline rather than treating the repo as blocked.
• State explicitly that git operations and prose gh calls belong in separate invocations, because a hook rejects the whole compound command.
• Every prose gh example in the template should carry the sign-off, so the rendered instance is correct by default.

---

drafted by Claude on behalf of Daniel Stephenson

[dmccoystephenson]

Correction — the central claim above is wrong

The original report asserted that --body-file is unsatisfiable under an attribution hook because the hook inspects the command string and cannot see the file. That is not correct, and the error is worth stating plainly because it was used to justify deferring #93's rule across the whole fleet.

The hook does read --body-file / -F targets from disk. The actual failure was self-inflicted: the call passed --body-file $SP/fwd1-pr.md, and because the hook receives the raw, unexpanded command string, $SP is not a resolvable path. The body was never read, so a correctly signed file was rejected.

Verified directly against the installed hook with three synthetic payloads:

Command form	File contains sign-off	Result
--body-file /root/.../signed.md	yes	allowed
--body-file /root/.../unsigned.txt	no	denied (correctly)
--body-file $SP/signed.md	yes	denied — $SP unexpandable

What the rule should actually say

#93's --body-file guidance stands and is safe to propagate, with one addition:

When passing a body via --body-file / -F, give a literal absolute path. An attribution or policy hook inspects the raw command string and cannot expand shell variables or ~, so --body-file "$SCRATCH/body.md" presents an unresolvable path and a correctly signed body is rejected as unsigned.

What still stands from the original report

Two findings are unaffected and remain worth encoding:

1. Every prose gh example in the template should carry the sign-off, so the rendered instance is correct by default. This was the first half of the original report and is unchanged.
2. A hook rejection aborts the entire Bash invocation. Chaining git commit && git push && gh pr create … means a rejection silently discards the commit and push as well, while presenting as a successful no-op. Keep git operations and prose gh calls in separate invocations, and verify with git log --oneline -1 / git ls-remote --heads origin <branch> rather than assuming the git half ran.

Consequence for the retrofit

The --body-file family (#93) was deferred across ~78 instances on the strength of the incorrect claim. That deferral should be lifted and the rule propagated in the next pass, with the literal-path caveat included.

---

drafted by Claude on behalf of Daniel Stephenson