Repository navigation
v0.4.0 — lg upgrade
요약
**lg upgrade**로 이전 spec_version의 프로젝트를 규칙대로 새 버전에 올린다. v0.3 적용 때 손으로 한 갱신(새 프로젝트를 임시로 만들어 파일 복사, 문서 버전 일괄 수정)에서 실제로 생긴 문제들을 요구사항으로 삼았다: 연구 문서의 버전 표기 누락, 실행 권한 손실, 사람이 고친 파일을 덮어쓸 위험, 같은 spec_version 안의 파일 차이.
주요 내용
lg upgrade [--dry-run] [--force]
- 사람이 항상 우선이다. 사람의 수정을 발견하면 지우지 않고 터미널에 알린다.
- 관리 문서(규칙·절차·도구): 그 버전 그대로면 새 버전으로 교체. 사람이 고쳤으면 아무것도 바꾸지 않고 멈춘다(코드 3).
--force면 덮어쓰고 원래 내용을.lg/pending/upgrade/에 남기며, 목록을 갱신 기록의forced에 적는다. - 사람이 채우는 관리 문서(stub 사양,
specs/README.md): 채웠으면 내용 유지,spec_version만 갱신.--force로도 덮어쓰지 않는다. .gitignore:# labgate:begin~# labgate:end관리 구역만 갱신. 사람이 지운 labgate 줄은 다시 넣지 않고, 사람이 더한 줄은 구역 밖에 둔다.- 연구 문서: frontmatter
spec_version만 올린다. 형식이 다르면 그대로 두고 알린다. AGENTS.md의 프로젝트 정보 줄은 사람이 고쳤어도 교체할 때 그대로 옮긴다..lg/project.yaml에 갱신 기록(upgrades)을 남긴다. 커밋하지 않는다: 사람이git diff로 확인하고lg commit(타입spec)으로 확정한다.- 에이전트는 실행하지 못한다(Claude Code deny).
버전 형식과 해시표
- spec_version은 정수, 문서 frontmatter는 정확히
spec_version: <정수>한 줄. spec_version은 마이너 버전에서만 바뀌고, 릴리즈된 spec_version의 템플릿은 다시 바꾸지 않는다(테스트가 막는다). - 릴리즈된 spec_version마다 관리 문서의 해시표를 패키지에 둔다(
hashes/2.json·3.json·4.json). 프로젝트에는 아무것도 기록하지 않으므로 기존 v0.2·v0.3 프로젝트도 같은 방식으로 판별된다. - 생성 파일의 분류는 경로 규칙 한 곳(
kinds.py)에 있다. dev 버전으로 만든 프로젝트는 지원하지 않는다.
호환성
- spec_version 4. 생성되는 프로젝트에
.gitignore관리 구역과lg upgradedeny가 추가됐다. 생성 파일 수는 그대로다. lg commit·lg draft는 spec_version 2–4를 지원한다.- spec_version 2·3 프로젝트는
lg upgrade로 4까지 올릴 수 있다.
확인
- 테스트 363개. 옛 프로젝트는 실제 v0.2.1·v0.3.0 tag의 labgate로 만들어서 올린다(CI가 tag를 받는다). 연구 프로젝트 사본에서 실제로 실행했다:
specs/conventions.md하나로 갱신 실패 →--force→ 관리 문서 교체, 연구 문서 20개 2→4, 실행 권한 유지, hook을 통과하는spec커밋. - Python 3.10–3.14 × 최신·최소 의존성, 생성 스크립트 Python 3.9.
설치·업데이트
pipx install --force git+https://github.com/qazcdesnu/labgate.git@v0.4.0
lg --version이미 만든 프로젝트를 올리는 방법: 프로젝트 폴더에서 에이전트 세션을 종료한 뒤 lg upgrade --dry-run → lg upgrade → git diff → git add -A && lg commit(타입 spec). 자세한 내용은 docs/guide/upgrade.md.