# Antigravity State Management & Git Worktree Rules

## State Tracking & Persistent Memory
- **Long-term Knowledge (MCP):** Use the MCP memory graph strictly for long-term, persistent facts such as architectural decisions, environment invariants, SSH mappings, and domain entities. Static developer preferences and rules are kept in git-tracked markdown files.
- **Transient State (Git):** Do NOT write transient task progress (e.g., "currently editing line 42") to MCP memory. Continue to use verbose, incremental local `git` commits to track short-term state and maintain rollback safety.

## Branching Strategy & Workflow (Git Worktrees)
- **Architecture:** This environment utilizes Git Bare repositories with worktrees (e.g., a `.bare` directory alongside branch directories like `master`, `feature-x`).
- **Navigation Rule (CRITICAL):** NEVER attempt to run tests, execute git commands, or invoke subagents against the root project folder or the `.bare` directory. ALWAYS navigate into the specific active worktree directory (e.g., `cd project-name/master`).
- **Never Modify Master Directly:** Do NOT make code modifications or dirty the working tree of the `master` or `main` directories.
- **Isolated Worktrees:** Before beginning a new task, create an isolated sibling worktree directory for a new feature branch. 
  - *Example:* From inside `master/`, run `git worktree add ../feat-my-new-task -b feat-my-new-task`.
- **Standard Workflow:** Change directory into the newly created worktree (`cd ../feat-my-new-task`) and make all verbose incremental commits there. 
- **Cleanup:** Once the task is complete, squashed, pushed, and merged, delete the local worktree branch (`git worktree remove ../feat-my-new-task`).
- **Initialization:** If the project is not using a bare worktree layout, invoke the `setup-bare-worktree` skill first.