Feedback git workflow merge deploy human gate
name: Justin: agent auto-handles PR plumbing, but merge and deploy always need his explicit approval description: Justin's standing policy on CreatorTrack git/deploy automation: full auto up to opening a PR, but merge and deploy require his go-ahead every time. type: feedback
Justin's policy, stated directly 2026-07-15: the agent should automate all the git plumbing (pull main, branch/worktree, build, commit, push, open PR) without him having to think about it. But he does not want auto-merge or auto-deploy. He wants to be reminded/reached out to for merge approval, and deploy always needs his explicit approval because the site goes down briefly.
Why: He's not a software developer by trade and is still learning the git/GitHub mental model. He doesn't want PR review to become 'homework' he has to remember to do on github.com, but he does want the two consequential, hard-to-reverse actions (merge into main, deploy to prod) gated behind his yes. He explicitly said 'if sending the PRs to github as claude and codex creates a job for me to do then I don't want it' — meaning the agent (Claude or Codex), not Justin, should still be the one that runs gh pr merge, just only after Justin says the word.
How to apply: For CreatorTrack (and similar deployed-app) work: agents should pull/branch/build/commit/push/open-PR autonomously, then ping Justin's phone via forge_notify.sh that a PR is ready ('PR ready to merge' pattern), then stop and wait. Never auto-merge, never auto-deploy. When Justin approves, the agent (not Justin) runs the merge and/or deploy commands. This is now also encoded in [[project_git_github_is_boss_policy]] and CreatorTrack AGENTS.md / forge CLAUDE.md, but the human-approval-gate nuance (agent still executes, Justin just approves) is the key detail worth remembering directly.
[auto-memory session 577603bc-d3a9-4b19-bb8e-6db80243b054, confidence 0.90, mode direct]