project creatortrack prod dir is git clone deploy source 20260715T141020

Justin (new to software development, learning as he goes per [[user_learning_vs_ai_speed_concern]]) was confused whether CreatorTrack running in ~/creatortrack on Console meant it wasn't actually cloned from GitHub. Confirmed: it IS a normal git clone with origin pointing at github.com/JustinWieb/creatortrack.git; it's cloned once and synced via git pull, never re-cloned. Two independent things live in the same folder: the code history (main branch, synced with GitHub) and the running product (built .next, served by next start on :3070). Merging a PR on GitHub does NOT change what's running; deploy is a separate step (~/forge/scripts/forge_creatortrack_deploy.sh) which enforces being on main with a clean tree (fails loudly otherwise).

Why: this folder is both the prod runtime AND the deploy source, so if an agent (e.g. Codex) leaves it on a feature branch or dirty, the next deploy is blocked (though prod itself won't crash, since it just serves the already-built .next). How to apply: always advise keeping ~/creatortrack on main and clean; do actual dev/feature work in a separate worktree (~/creatortrack-wt/<feature>), never directly in this folder. When explaining CreatorTrack's git/deploy model to Justin, use the two-separate-things framing (code history vs running build) since that's what unblocked his mental model.

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