# Two-Developer Collaboration Protocol

This doc exists to stop the two of us from overwriting each other's work,
duplicating effort, or breaking each other's in-progress modules. Read it
once, then just follow the branch/PR/ownership rules below.

## 0. Fix identity mismatch first (one-time, each dev)

Task logs (`dailytasklogs/<name>/`) are keyed off your git branch name, or
your `git config user.name` if the branch name isn't a person's name. Right
now Santosh's branch is `santosh` but `git config user.name` is `Santosh971`
— two different values — so logs have been splitting into **two** folders
(`dailytasklogs/santosh/` and `dailytasklogs/santosh971/`) instead of one.

Run this once, each of you, so your identity is consistent everywhere:

```bash
git config user.name "santosh"      # Santosh — must match your branch name
git config user.name "rahuln2532"   # Rahul — must match your branch name
```

Going forward, always branch off your own name (`santosh/...`,
`rahuln2532/...`) so logs stay in one folder per person.

## 1. Module ownership

Split by folder, not by day or by feature-of-the-week — this is what
actually prevents two people editing the same file.

| Owner | Frontend modules (`src/frontend/src/modules/`) | Backend routes |
|---|---|---|
| **Santosh** | `admin`, `onboarding`, `org-admin`, `settings`, `system` | `auth.js`, user/role/company/campus routes, security/2FA, super-admin routes |
| **Rahul** | `marketing`, `generation`, `automation`, `billing`, `brand` | the `aiContext*.js` family, content/generation services, billing/payment routes |

**Shared territory** (`modules/shared`, `modules/foundation`, anything in
`src/backend/src/models`, `src/backend/src/middleware`, `src/backend/src/index.js`,
root config files): treat as joint-custody. Never edit silently — see Rule 3.

If a task doesn't fit either module cleanly, say so before starting rather
than guessing — 30 seconds of asking beats an hour of conflict resolution.

## 2. Git workflow

- `main` is the only branch either of you merges into directly — never push
  straight to it.
- Each of you works on your own long-lived personal branch (`santosh`,
  `rahuln2532`), and cuts short-lived feature branches off it if a task is
  large enough to want its own PR (`santosh/billing-refund-flow`).
- **Pull + rebase onto `main` at the start of every session**, before you
  start editing anything. This is the single biggest conflict-preventer.
- Open a PR to merge into `main` when a module/feature is done. The other
  dev reviews it — this is also the natural point to catch anything an AI
  agent generated too fast or outside its lane.
- Turn on branch protection on `main` in GitHub (Settings → Branches):
  require a PR + 1 approval before merge, so neither of you (or a Claude
  Code session acting on your behalf) can push to `main` by accident.
- Keep commits small and frequent rather than one giant end-of-day commit —
  smaller diffs are easier to review and rebase.

## 3. Touching shared/foundation code

Before editing anything in the shared territory above:

1. Post in your shared chat (see Rule 4): "touching `models/User.js` for
   X, should be done by [time]."
2. Keep the change small and finish it in one sitting if possible — don't
   leave shared files mid-refactor overnight.
3. Pull immediately after merging a shared-territory PR so the other dev
   isn't diffing against a stale version.

## 4. Daily sync (async, since you're on separate machines)

- Claude Code sessions on two different machines don't talk to each other —
  git is the only thing that actually syncs your work. Don't rely on Claude
  to "know" what the other dev is doing.
- Use a real-time channel (WhatsApp/Slack/whatever you already use) for the
  one-line "starting on X now" / "done, pushed, PR up" pings — this is
  where you actually avoid stepping on each other, not in code.
- Each morning, skim the other person's log file
  (`dailytasklogs/<their-name>/<today>.md`) — it's already an automatic,
  factual changelog of exactly what they touched and why, generated by
  Claude Code per the CLAUDE.md protocol. Cheaper than a standup meeting.

## 5. Conflicts and hotfixes

- If you both need to touch the same file the same day, whoever finishes
  first pushes and pings the other to rebase before continuing — don't let
  two people edit the same file in parallel for hours.
- For an urgent production fix, branch off `main` directly
  (`hotfix/<short-name>`), fix, PR, merge, then both of you rebase your
  personal branches onto the updated `main` immediately.