Skip to content

Project git github is boss policy

Justin decided (2026-07-15) that GitHub main is the boss for both forge and creatortrack repos, resolving a divergence risk between the Codex PR-merge flow (GitHub leads) and the existing /ship local-merge flow (Console led, never pushed).

Changes made same session: - CreatorTrack AGENTS.md (imported by CLAUDE.md): added "Git workflow: GitHub is the boss" block, shipped via PR #4. - forge CLAUDE.md: added "Git workflow (GitHub is boss)" rule under Engineering standards (now also reflected in the auto-loaded CLAUDE.md content itself). - forge /ship skill: now runs git push origin main immediately after the local merge, closing the gap that let Console drift ahead of GitHub undetected. - forge has no AGENTS.md (Codex doesn't run there); only add one if Codex is later run inside ~/forge.

Why: the Codex PR flow and /ship's local-merge flow are two different doors into the same main; without a single canonical direction and without /ship pushing, Console's main silently ran ahead of GitHub (confirmed live: forge's Console main was found ahead by commit range ce96032..ff8738f when this was fixed).

How to apply: for CreatorTrack, always work in a worktree/branch, push, open a PR, merge on GitHub, then git pull --ff-only on Console before deploying, never hand-commit to the prod checkout's main. For forge, commit+push directly is fine but push immediately after every commit to main. After any merge on either repo, verify Console and GitHub main match before starting new work.

[auto-memory session 577603bc-d3a9-4b19-bb8e-6db80243b054, confidence 0.90, mode direct]

Auto-memory addendum 2026-07-15T14:39:09.322898

Justin decided (2026-07-15) that GitHub is boss for git workflow across both forge and creatortrack, resolving prior ambiguity between edit-main-directly (Console-is-boss) and worktree->PR->merge-on-GitHub styles.

Rule: GitHub main is the source of truth. CreatorTrack changes go branch -> push -> PR -> merge on GitHub -> git pull --ff-only -> deploy; never hand-commit to the prod checkout (~/creatortrack). Forge keeps its convention of direct commit+push to main, but must push immediately after committing so it never drifts.

Enforcement made concrete this session: - ~/creatortrack/AGENTS.md (imported by CreatorTrack's CLAUDE.md via @AGENTS.md) got a new "Git workflow: GitHub is the boss" block, shipped via PR #4. - ~/forge/CLAUDE.md got a "Git workflow (GitHub is boss)" rule under Engineering standards (already reflected in current CLAUDE.md contents). - The /ship skill (~/forge/.claude/skills/ship/SKILL.md) was updated to run git push origin main right after merging, closing the gap where /ship previously merged but never pushed. - Confirmed live: forge's own Console main was found drifted ahead of GitHub (range ce96032..ff8738f unpushed) at the time this rule was written, proving the drift risk was real, not theoretical. - No ~/forge/AGENTS.md exists (forge only runs Claude, not Codex); if Codex is ever run inside forge, an AGENTS.md with this same rule should be added.

Why: prevents the "both ahead of each other" divergence trap between Console-committed and GitHub-merged changes to the same main, especially when multiple agents/sessions touch the same repo concurrently.

How to apply: before recommending any git flow for forge or creatortrack, default to branch->PR->merge-on-GitHub->pull for CreatorTrack; for forge, commit+push immediately. Always insist /ship (or any deploy path) ends with git push origin main. Flag any other agent's plan that proposes hand-editing ~/creatortrack main directly and deploying without a push.

[auto-memory session 577603bc-d3a9-4b19-bb8e-6db80243b054, confidence 0.90]