cds-ai/atvm/git-guide.md

# Git Guide

This file records ATVM-specific git workflow preferences for `/home/aw/code/cds/atvm`.

## Repository Reference
- Do not assume the controller repo by default for every ATVM git request.
- Only switch the default drafted repo to `/root/cdc-e2e-cyp-12.17.4` when the operator explicitly asks for the `e2e cypress` repo or a close variation such as `give me a git for the e2e cypress`.
- When the operator explicitly targets the `e2e cypress` repo, draft the git command itself for that controller repo.
- Do not wrap drafted git commands in an SSH login command to the controller unless the operator explicitly asks for the SSH wrapper too.

## Execution Rule
- For this ATVM workspace, do not automatically perform any git-related command.
- Do not run `git status`, `git add`, `git commit`, `git push`, `git pull`, `git fetch`, `git stash`, `git checkout`, `git switch`, `git rebase`, `git merge`, `git diff`, or any other git command unless the operator explicitly asks for that exact command to be executed.
- By default, git requests in this workspace are draft-only requests.
- Respond by preparing the exact commands for operator review, not by executing them.
- Always write the drafted ATVM git commands to `/tmp/commit.txt` so the operator can copy and paste them.
- Assume the operator will always run ATVM git commands manually.

## SSH Default
- When drafting git commands for the explicitly requested `e2e cypress` controller repo and SSH-backed git access is needed, use this exact prefix:
  `GIT_SSH_COMMAND='ssh -i ~/.ssh/id_ed25519_anthony -o IdentitiesOnly=yes'`
- Prefer complete copy-pasteable command sequences that include that prefix for `git fetch`, `git pull`, and `git push` examples when applicable.

## Commit Message Requests
- If the operator asks for a git commit description, draft the proposed commit message first.
- When warranted by the size or complexity of the change, provide both:
  - a concise commit title/summary line
  - a detailed commit description/body listing the key changes
- The proposed `git commit` command should match the full proposed message, including the detailed body when one is warranted.
- After the proposed commit message, show the exact `git commit` command that would be used.
- Write the proposed ATVM git commands to `/tmp/commit.txt`.
- When drafting a commit for the explicitly requested `e2e cypress` controller repo, present the plain `git add ...` / `git commit ...` command sequence the operator should run after logging into the controller repo, not an SSH-wrapped controller-login command.
- If the operator asks for a git commit, do not commit immediately.
- First show both:
  - the proposed commit description/message
  - the exact `git commit` command planned for execution
- When a detailed body is warranted, do not reduce the proposed commit to only the short title at execution time.
- Do not run `git commit` immediately after drafting the message.
- Wait for explicit user approval before creating the commit.
- Do not treat a request such as "give me the git commit" or "make the commit" as approval by itself.
- Do not treat a request such as "create a git for me", "show me a proposed git commit", "prepare the commit", or any similar commit-related wording as approval by itself.
- Treat all of the following as approval-gated prepare-only requests, not as permission to run `git commit`:
  - `create me a git`
  - `create a git`
  - `create a git description`
  - `make me a git`
  - `make a git`
  - `make me a git description`
  - `create me a git description`
- Treat close variations of those phrases with the same intent the same way.
- If the request means "prepare or create git/commit wording or a commit", ask for approval first before running any commit action.
- Treat every commit-related request as prepare-and-show-only until the operator explicitly approves the commit after seeing the proposed message or exact command.
- Only execute `git commit` after the operator explicitly approves the displayed commit command.
- If there is any ambiguity about whether the operator is asking for preparation versus execution, default to not committing.

## Push Requests
- For this workspace, never execute `git push` from the assistant.
- When the operator asks to push, show the exact push command only.
- Do not hardcode `origin main` in this ATVM-local guide.
- When drafting a push command, use the operator's requested remote/branch if provided.
- If the operator does not specify the remote/branch, either:
  - draft a generic SSH-prefixed `git push` command, or
  - draft the exact remote/branch already established in the current ATVM context
- Default generic push form:
  `GIT_SSH_COMMAND='ssh -i ~/.ssh/id_ed25519_anthony -o IdentitiesOnly=yes' git push`
- When reminding the operator about the push command after a commit proposal or completed commit for the explicitly requested `e2e cypress` controller repo, always display the SSH-prefixed push command without assuming `origin main` unless that remote/branch was explicitly established.
- Every commit draft response for the explicitly requested `e2e cypress` controller repo must include the SSH-prefixed push example.
- Every post-commit response for the explicitly requested `e2e cypress` controller repo must include the SSH-prefixed push example.
- Write the proposed push command to `/tmp/commit.txt`.

## Commit Scope
- When committing, include only the files relevant to the approved change.
- Leave unrelated worktree changes uncommitted unless the operator explicitly asks to include them.