d34b532(v4.6.0 릴리스 커밋)가 병합 워크트리의 .venv 심볼릭 링크(/Users/.../multi-agent-mux/.venv)를 커밋했다. 이 저장소의 .gitignore 규칙 .venv/ 는 디렉터리에만 맞고 링크에는 맞지 않았기 때문이다. 이 커밋으로 갱신된 체크아웃은 기존(무시된) .venv 디렉터리가 경고 없이 링크로 바뀌었다(재현 확인). 1134d74 에서 이 저장소는 추적을 해제하고 규칙을 .venv 로 바꿨다.
문제
설치 스크립트는 대상 프로젝트의 .gitignore 관리 블록에 여전히 디렉터리 전용 규칙을 쓴다.
deploy/install.sh:549 — "/.venv/\n"
deploy/install_mam.sh:249 — "/.venv/\n"
#21 운영 모델은 워크트리 준비 시 ln -s "$MAIN/.venv" "$WT/.venv" 를 쓰므로, MAM 을 설치한 프로젝트가 이 모델을 따르면 같은 사고가 난다.
## 배경
`d34b532`(v4.6.0 릴리스 커밋)가 병합 워크트리의 `.venv` 심볼릭 링크(`/Users/.../multi-agent-mux/.venv`)를 커밋했다. 이 저장소의 `.gitignore` 규칙 `.venv/` 는 **디렉터리에만** 맞고 링크에는 맞지 않았기 때문이다. 이 커밋으로 갱신된 체크아웃은 기존(무시된) `.venv` 디렉터리가 경고 없이 링크로 바뀌었다(재현 확인). `1134d74` 에서 이 저장소는 추적을 해제하고 규칙을 `.venv` 로 바꿨다.
## 문제
설치 스크립트는 대상 프로젝트의 `.gitignore` 관리 블록에 여전히 디렉터리 전용 규칙을 쓴다.
- `deploy/install.sh:549` — `"/.venv/\n"`
- `deploy/install_mam.sh:249` — `"/.venv/\n"`
#21 운영 모델은 워크트리 준비 시 `ln -s "$MAIN/.venv" "$WT/.venv"` 를 쓰므로, MAM 을 설치한 프로젝트가 이 모델을 따르면 같은 사고가 난다.
## 제안
1. 두 스크립트의 관리 블록 규칙을 `/.venv`(파일·디렉터리·링크 모두)로 바꾼다.
2. 기존 설치의 관리 블록도 갱신되도록 update 경로를 확인한다.
3. 배포 자산 해시 등 무결성 값 갱신이 필요한지 확인하고 테스트를 추가한다.
4. #21 다음 작업(항목 4 워크트리 준비 헬퍼)과 함께 처리한다.
## 환경 정보
- main `1134d74` (v4.6.0)
커밋 fadd38c (fix(deploy): #27), #21 2단계 루프 A 에서 구현.
deploy/install.sh·deploy/install_mam.sh 의 관리 블록 규칙을 /.venv/ → /.venv 로 바꿨다. 이제 .venv 가 디렉터리·파일·심볼릭 링크 어느 형태여도 무시된다(워크트리 준비 헬퍼가 만드는 .venv 링크 포함).
기존 설치: 다음 install/update 가 마커 사이의 관리 블록을 통째로 다시 쓰므로 새 규칙을 받는다. 블록 밖 사용자 행은 유지된다.
무결성 값: .gitignore 는 asset_hashes.txt 와 설치 매니페스트 어디에도 없으므로 영향이 없다.
테스트: W10(두 설치 스크립트, .venv 링크·파일·디렉터리 모두 무시), W11(#27 이전 블록 교체, 블록 밖 사용자 행 보존, .gitignore 가 원장 밖에 머묾).
## 해결 — PR #29 (병합 시 닫힘)
커밋 `fadd38c` (`fix(deploy): #27`), #21 2단계 루프 A 에서 구현.
- `deploy/install.sh`·`deploy/install_mam.sh` 의 관리 블록 규칙을 `/.venv/` → `/.venv` 로 바꿨다. 이제 `.venv` 가 디렉터리·파일·심볼릭 링크 어느 형태여도 무시된다(워크트리 준비 헬퍼가 만드는 `.venv` 링크 포함).
- 기존 설치: 다음 install/update 가 마커 사이의 관리 블록을 통째로 다시 쓰므로 새 규칙을 받는다. 블록 밖 사용자 행은 유지된다.
- 무결성 값: `.gitignore` 는 `asset_hashes.txt` 와 설치 매니페스트 어디에도 없으므로 영향이 없다.
- 테스트: W10(두 설치 스크립트, `.venv` 링크·파일·디렉터리 모두 무시), W11(#27 이전 블록 교체, 블록 밖 사용자 행 보존, `.gitignore` 가 원장 밖에 머묾).
v4.7.0 (PR #29, fadd38c, main 6fc9194) 로 해결. deploy/install.sh·install_mam.sh 의 관리 블록이 .venv 를 파일·디렉터리·링크 어느 형태로도 무시하고, 재설치는 옛 규칙만 바꾸고 사용자 줄은 보존한다(w10·w11). 아울러 worktree_prepare.sh 는 더 이상 .venv 심링크를 만들지 않고 워크트리 자체 venv 를 만든다(링크가 남아 있으면 exit 1).
v4.7.0 (PR #29, `fadd38c`, main `6fc9194`) 로 해결. `deploy/install.sh`·`install_mam.sh` 의 관리 블록이 `.venv` 를 파일·디렉터리·링크 어느 형태로도 무시하고, 재설치는 옛 규칙만 바꾸고 사용자 줄은 보존한다(w10·w11). 아울러 `worktree_prepare.sh` 는 더 이상 `.venv` 심링크를 만들지 않고 워크트리 자체 venv 를 만든다(링크가 남아 있으면 exit 1).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
배경
d34b532(v4.6.0 릴리스 커밋)가 병합 워크트리의.venv심볼릭 링크(/Users/.../multi-agent-mux/.venv)를 커밋했다. 이 저장소의.gitignore규칙.venv/는 디렉터리에만 맞고 링크에는 맞지 않았기 때문이다. 이 커밋으로 갱신된 체크아웃은 기존(무시된).venv디렉터리가 경고 없이 링크로 바뀌었다(재현 확인).1134d74에서 이 저장소는 추적을 해제하고 규칙을.venv로 바꿨다.문제
설치 스크립트는 대상 프로젝트의
.gitignore관리 블록에 여전히 디렉터리 전용 규칙을 쓴다.deploy/install.sh:549—"/.venv/\n"deploy/install_mam.sh:249—"/.venv/\n"#21 운영 모델은 워크트리 준비 시
ln -s "$MAIN/.venv" "$WT/.venv"를 쓰므로, MAM 을 설치한 프로젝트가 이 모델을 따르면 같은 사고가 난다.제안
/.venv(파일·디렉터리·링크 모두)로 바꾼다.환경 정보
1134d74(v4.6.0)해결 — PR #29 (병합 시 닫힘)
커밋
fadd38c(fix(deploy): #27), #21 2단계 루프 A 에서 구현.deploy/install.sh·deploy/install_mam.sh의 관리 블록 규칙을/.venv/→/.venv로 바꿨다. 이제.venv가 디렉터리·파일·심볼릭 링크 어느 형태여도 무시된다(워크트리 준비 헬퍼가 만드는.venv링크 포함)..gitignore는asset_hashes.txt와 설치 매니페스트 어디에도 없으므로 영향이 없다..venv링크·파일·디렉터리 모두 무시), W11(#27 이전 블록 교체, 블록 밖 사용자 행 보존,.gitignore가 원장 밖에 머묾).v4.7.0 (PR #29,
fadd38c, main6fc9194) 로 해결.deploy/install.sh·install_mam.sh의 관리 블록이.venv를 파일·디렉터리·링크 어느 형태로도 무시하고, 재설치는 옛 규칙만 바꾸고 사용자 줄은 보존한다(w10·w11). 아울러worktree_prepare.sh는 더 이상.venv심링크를 만들지 않고 워크트리 자체 venv 를 만든다(링크가 남아 있으면 exit 1).