Dialogue · Design notes · Repo sync
← Design notes

Two machines, one repo — how CW's Mac and your PC stay in sync

Archived — The Mac-mini / persona-branch / Drive-sync collaboration model described here is retired; personas are now authored in-tree on main, and this is the sole working copy. Kept for provenance; no longer maintained. See the dev loop for current docs.

You and CW (GitHub Hiroki-CoC) now work on the same private repo from two different computers — she authors persona profiles on her Mac Mini, you review and merge on your PC. This page walks through everything we set up and, for each step, what it's actually for. The throughline: GitHub is the only thing the two machines share. They never copy files to each other directly. Every change rides up through a reviewed Pull Request and comes back down with a git pull.

Recorded 2026-06-04 · collaborator: CW (Hiroki-CoC, Write access) · repo: enovyhoo/Multi-Agent-Dialog (private)

The one rule that makes it work: nothing travels Mac-to-PC directly. CW pushes a branch → you review & squash-merge on GitHub → both machines run git pull. That single hub-and-spoke loop keeps the two clones identical and makes it impossible for her work to land on main unreviewed.

1 · The shape: one hub, two clones

Picture GitHub as a hub in the middle and each computer as a spoke. Work flows up (push), gets reviewed in the hub, then flows down (pull) to both machines so they match again.

GitHub · origin/main the shared hub — private repo main · persona/* branches · PR gate ② review → ③ squash-merge CW's Mac Mini ~/CODES — local clone (NOT in iCloud / Drive) authors personas Your PC …/Google Sync/… — local clone (repo here; Drive ≠ sync channel) reviews & merges ① push + PR ④ git pull ④ git pull auto deploy never machine-to-machine
push (up to hub) pull (down to clones) roster-deploy bot (auto)

Why the channel is Git, not Google Drive. Your repo folder happens to live inside Google Sync, but the collaboration never uses Drive. Two machines syncing one .git folder through a file-sync service corrupts it — they fight over the same internal files. Git is the tool built for multi-machine work; Drive is not. That's why CW's clone lives in ~/CODES, a plain local folder deliberately outside iCloud/Drive.

2 · The rails we laid once

One-time setup. Each row is a thing we did and the job it does.

StepWhat we didIts function
ChannelUse the GitHub remote enovyhoo/Multi-Agent-Dialogthe hub both machines sync through — replaces any file-sync idea
WorkflowBranch + Pull RequestCW's work waits on a branch and is reviewed before it can reach main
CODEOWNERSAdded .github/CODEOWNERS = * @enovyhooauto-requests you as reviewer on every PR she opens
CollaboratorAdded Hiroki-CoC to the repogives her push access (a personal repo grants Write by default)
GitHub ProUpgraded the account ($4/mo)makes branch rules actually enforced on a private repo (free plan doesn't)
protect-mainRuleset: block force-push + restrict deletionno one can rewrite history or delete main — the catastrophe net

We deliberately left "require a pull request" off in the ruleset — turning it on would also block your own direct pushes and the roster-deploy bot. So the server enforces the catastrophic protections (no force-push, no deletion); the workflow (CW branches + you review) is what keeps bad content off main.

3 · Her Mac, bootstrapped once

Her CC session did this from a kickoff prompt — clone, set identity, skip the API key. Three jobs:

# 1 · clone into a plain local folder — NOT inside Drive/iCloud mkdir -p ~/CODES && cd ~/CODES git clone https://github.com/enovyhoo/Multi-Agent-Dialog.git # 2 · stamp her identity on this repo only (attribution in history) git config user.name "Hiroki-CW" git config user.email "chenwenaiba@gmail.com" # 3 · no .env / API key — persona authoring doesn't need the room app
ChoiceFunction
Clone to ~/CODESa real local working copy, safely outside any file-sync folder
Set user.name / user.emailevery commit she makes is attributed to her in git log / blame / the PR
Skip .envthe API key is only for running the room app; writing profiles needs none

4 · The loop she repeats per persona

Every profile flows through the same eight steps. Steps ①–⑤ are CW, ②–③ (on GitHub) are the gate, ⑥ is you, ⑦ is both. The function of each:

5 · The sync itself, zoomed in

"Syncing" is really just four verbs. Push and pull move commits between a clone and the hub; the PR is the gate in between.

VerbDirectionWhat it does
git pushclone → GitHubuploads your branch's commits to the hub
git fetchGitHub → clone (refs only)downloads new commits but does not change your files yet
git pullGitHub → clone (+apply)fetch plus fast-forward your files to match the hub
Pull Requestbranch → main (on GitHub)proposes & gates the merge; review happens here

What you literally saw when we synced your PC after the Elon Musk merge: Git reported your clone was behind 1, then fast-forwarded it to match the hub — no edits, no conflict, just catching up.

# before — your clone is one merge behind the hub ## main...origin/main [behind 1] # git pull → fast-forward (just moves your pointer up to match) Updating 80c25cd..7d82d6f Fast-forward prototype/personas/elon-musk/profile.md | 235 +++++++++ … 9 files changed, 2484 insertions(+)

One extra wrinkle on your PC: a roster-deploy bot auto-pushes to origin/main on its own (the repo sits in a synced folder). So origin/main can move without you. The habit that handles it: always git pull before you start, and never force-push. That's also why a couple of personas you thought were "local-only" turned out to already be on the hub — the bot had pushed them, and your pull quietly absorbed them.

6 · What can and can't crash main

Two layers, kept separate on purpose. The server stops the irreversible disasters; the workflow stops bad content.

✓ Server-enforced (ruleset)

Force-push blocked + deletion restricted on main. History can never be rewritten or wiped — by anyone, including a buggy script. This is the hard, irreversible-disaster net, live now that you're on Pro.

○ Workflow-enforced (convention)

A normal push to main is still allowed (so you + the bot keep working). What keeps CW's content off main is the branch + PR + your review loop — backed by the "never commit to main" rule saved in her CC's memory.

Net effect: the worst CW can do by accident is land a commit on her own branch, which you'd see in the PR before it ever reaches main. A markdown profile can't "crash" anything at runtime — the real risk was always Git-level mistakes, and those are now fenced off.

7 · Cheat sheet — who runs what, when

MomentWhoActionFunction
Start a personaCWgit checkout main && git pullbegin from the latest shared main
CWgit checkout -b persona/<slug>isolate the work on a branch
AuthorCW“create a profile of X” in CCgather → author → cold-audit
ShipCWgit add · commit · push -usnapshot + upload the branch
CWgh pr createpropose the merge; you're auto-requested
ReviewYouread diff + audit.md → Squash & mergethe gate; work joins main
SyncBothgit checkout main && git pullbring both clones to the new main
Bottom line: the two machines are kept identical by a loop, not a copy. CW pushes up, you gate in the middle, both pull down. Anything that doesn't pass your review simply waits on a branch — and history itself is now un-wreckable. The setup phase is over; from here it's just repeat-per-persona.

Related