install-maintenance-graft-rtk-ponytail-lite

프롬프트

# 검증된 설치 및 유지보수 — Graft + RTK + Ponytail lite

현재 저장소에서 다음 스택을 설치, 업데이트, 수리 또는 검증하는 작업을 수행하고 있습니다:

- Graft: 코드 이해, 로컬 그래프, LSP 확장.
- RTK: 터미널 노이즈 감소.
- Ponytail: 호환 시 네이티브 통합이 가능한 라이트 정책.

읽기 전용 인벤토리부터 시작하세요. 그 후 아래 누락된 질문을 하십시오.
답변을 받은 후, 최종 점검까지 권한이 부여된 작업을 수행합니다.

클라이언트와 범위를 결정하기 전에는 설치를 시작하지 마십시오.
이 대화에서 이미 결정된 사항에 대해 다시 묻지 마십시오.

## 1. 인벤토리, 그리고 사용자 선택

### 수정 없이 인벤토리

다음을 식별하세요:

- OS, 아키텍처, 셸, 환경: 로컬 머신, WSL, SSH, 컨테이너;
- 저장소 루트, 작업 트리, Git 상태 및 진행 중인 Git 작업;
- Git, Node, npm, RTK, Graft 및 사용 가능한 클라이언트의 실제 경로, 버전, 설치 방법;
- Claude Code, Codex, Kimi, Cursor Agent CLI, Cursor IDE를 별도로;
- Gemini, Copilot CLI 또는 이미 존재하는 기타 클라이언트(선택적 대상);
- 실제 사용 중인 구성 디렉터리, 리디렉션 변수, AgentsRoom과 같은 오케스트레이터;
- 기존 사용자, 프로젝트, 플러그인 및 상속된 훅 구성.

`agent`의 신원을 Cursor로 간주하기 전에 반드시 확인하세요.
존재하는 바이너리가 인증, 훅 기능, MCP 로딩을 증명하지 않습니다.

이 인벤토리 중에는 자동 업데이트, 연결 또는 설치를 실행하지 마십시오.
비밀 값은 절대 공개하지 마십시오.

간단한 표를 제시하세요:
클라이언트 | 바이너리/버전 | 유효 구성 | 알려진 상태.

### 한 번에 묻는 질문

답변이 없는 질문만 하십시오:

1. 작업:
   - 누락된 구성 요소 설치 및 호환 버전 유지.
   - 스택을 검증된 안정 버전으로 업데이트.
   - 기존 설치 수리, 버전 유지.
   - 수정 없이 검증만.

2. 클라이언트:
   - 감지된 모든 클라이언트.
   - 실제 감지된 목록에서 선택.
   - 부재 클라이언트 일부에 대한 구성도 준비.

3. 통합 범위:
   - 공유 프로젝트: 저장소용 휴대 가능한 구성.
   - 개인 프로젝트: 이 저장소에 대한 활성화, 버전 관리되지 않는 로컬 파일.
   - 전역 사용자: 이 사용자의 프로젝트에 대한 활성화.
   - 혼합: 클라이언트 또는 구성 요소별 별도 선택.

범위가 혼합인 경우 필요한 명확화만 요청하세요.

업데이트 시 이미 알려지지 않은 경우 버전 제약도 요청하세요.
그렇지 않으면 명확한 안정 버전을 제안하세요.

클라이언트 애플리케이션 자체는 설치하거나 업데이트하지 마십시오:
작업은 Graft, RTK, Ponytail 및 필요한 종속성에 관한 것입니다.
구버전 클라이언트는 필요한 버전과 남은 작업과 함께 보고됩니다.

### 선택 사항 구체화

작성 전에 계획된 결과를 표시하세요:

구성 요소/클라이언트 | 대상 버전 | 범위 | 대상 파일 | 공유 효과 | 대체

특히 다음을 설명하세요:

- 사용자 수준에 설치된 실행 파일은 여러 저장소에 서비스할 수 있습니다.
- 이 실행 파일을 업데이트하면 모든 로컬 사용자가 영향을 받습니다.
- 플러그인은 전역 캐시를 가질 수 있지만 프로젝트별 활성화가 가능합니다.
- 프로젝트별 훅은 여전히 공유 상태를 사용할 수 있습니다.
- Graft 인덱스는 저장소/작업 트리별로 고유합니다.
- 오케스트레이터가 제공하는 전역 구성은 프로젝트에 고립될 수 있습니다: 이름뿐 아니라 실제 범위를 확인하세요.

선택을 얻으면 반복 확인 없이 진행하세요.
범위 확장이나 물리적 솔루션 변경이 필요한 제한이 있을 때만 새 결정을 요청하세요.

## 2. 실행 규칙

순서:
인벤토리 → 선택 → 백업 → RTK → Graft/LSP → Ponytail → 지침 → 검증 → 보고.

저장소 지침과 관리 정책을 준수하세요.
파일이 AgentsRoom 또는 다른 오케스트레이터에 의해 관리되는 경우,
공식 메커니즘을 사용하고 생성된 파일을 직접 수정하지 마십시오.

각 수정 전:

- JSON/JSONC/TOML 구성의 형식 및 구조 검증;
- 영향을 받는 파일을 저장소 외부에 백업, 접근 제한;
- 롤백에 필요한 버전 및 요소 기록;
- 설치 프로그램의 드라이런이 있으면 검토.

잘못된 파일은 빈 구성으로 대체해서는 안 됩니다.

다른 MCP, 훅, 권한, 지침, 주석(가능한 경우), 상태 라인을 보존하며 구성을 병합하세요.
승인 규칙이나 신뢰 지문은 변경하지 마십시오.

기존 Git 변경 사항을 보존하세요. 커밋, 푸시, 리셋, 클린, 스태시, 애플리케이션 코드 변경 금지.
해결되지 않은 충돌이나 진행 중인 Git 작업이 있으면 저장소 내 쓰기를 중단하고 독립 진단을 계속하세요.

Graphify, CodeGraph, Caveman, Headroom은 설치하지 마십시오.
오래된 충돌 통합은 정확한 식별, 백업, 권한 범위 내에서만 제거합니다.
다른 곳에서 사용하는 도구를 전역 제거하지 마십시오.

오류는 종속 단계만 차단하며 독립 클라이언트는 차단하지 않습니다.
제한을 우회하기 위해 단계를 성공으로 선언하지 마십시오.

## 3. 기능 및 범위: 구성 전에 검증

설치된 버전의 도움말과 사용할 게시 버전에 해당하는 문서를 참조하세요:

- https://github.com/rtk-ai/rtk
- https://github.com/trailhq/Graft
- https://github.com/DietrichGebert/ponytail
- 선택한 각 클라이언트의 공식 문서.

main/develop 브랜치는 릴리스에 없는 기능을 설명할 수 있습니다.
의심스러운 옵션은 릴리스, 도움말 또는 제공된 코드를 확인하세요.

각 통합에 대해 다음을 정리하세요:

클라이언트 | 사용 가능한 프로젝트 훅 | 호환 설치 프로그램 |
활성화 범위 | 상태 범위 | 증거

혼동하지 마십시오:
"클라이언트가 프로젝트 훅을 허용한다"
와 "이 도구의 설치 프로그램이 프로젝트 수준에서 이를 설치할 수 있다"는 다릅니다.

현재 버전에서 재검증할 체크포인트:

- Claude: 사용자 설정, 공유 프로젝트 및 로컬 프로젝트.
- Cursor: 사용자 및 프로젝트 훅; IDE와 CLI를 별도로 테스트.
- Codex: 사용자/프로젝트 구성 및 플러그인 활성화;
  실제 사용 가능한 훅 메커니즘 확인.
- Kimi: 프로젝트별 훅 구성을 가정하지 않음;
  사용자 구성, 프로젝트 지침 및 실행 옵션 구분.
- Gemini/Copilot: 선택된 경우 자체 메커니즘 확인.

설치 관리자가 요청된 범위를 준수하지 않는 경우:

1. 적절한 공식 옵션을 찾습니다.
2. 그렇지 않으면, 프로토콜과 경로가 호환되는 경우에만 동일 어댑터의 문서화된 수동 구성을 사용합니다.
3. 그렇지 않으면, 명시적 지침/접두사로 대체 방식을 사용합니다.
4. 절대 전역으로 조용히 전환하지 않습니다.

로컬 등가물을 추가하기 전에 상속된 전역 훅을 검사하세요:
서로 교체하는 대신 누적될 수 있습니다.
보안 훅을 유지합니다. 활성 상태로 남아 있는 전역 효과를 보고합니다.

## 4. RTK

원본 `rtk-ai/rtk`, 버전, 도움말, 구성 및 `rtk gain`을 확인하세요.
`gain` 실패는 기본 또는 권한 문제에서 올 수 있습니다:
이는 패키지 불량의 충분한 증거가 아닙니다.

적절하다면 이미 사용 중인 관리자를 통해 설치 또는 업데이트하세요.
포뮬러 또는 패키지의 출처와 획득한 버전을 확인하세요.
동시 설치 및 불필요한 PATH 변경을 피하세요.
맹목적으로 `cargo install rtk`를 실행하지 마세요.

선택한 버전의 `rtk init --help`를 참조하세요.
클라이언트 및 범위별로 옵션을 선택하세요; 문서 예제에서 `-g`를 무조건 복사하지 마세요.

Codex 통합이 항상 단순한 지침이거나 항상 훅이 있다고 가정하지 마세요: 이는 RTK 버전에 따라 다릅니다.
초기화 옵션 간의 비호환성도 확인하세요.

실제로 읽은 구성에서 제외 항목을 병합하세요:

    [hooks]
    exclude_commands = ["graft", "curl", "playwright"]

기존 제외 항목을 유지하고 고려 여부를 확인하세요.
이 설정이 전역인 경우 수정 전에 이 효과를 알리세요.
허용된 범위 내에서 문서화된 메커니즘으로 선택적 텔레메트리를 비활성화하세요.

RTK는 셸 명령을 재작성할 수 있는 유일한 구성 요소입니다.
보안, 감사 및 승인 훅은 계속 적용됩니다.

문서화된 호환성 없이 Claude 훅을 다른 클라이언트에 복사하지 마세요.
효과적인 재작성 없이 명시적 접두사 `rtk`를 구성하세요.
중복 훅과 중복 접두사를 피하세요.

## 5. LSP와 함께하는 Graft

### 설치 및 개인정보 보호

패키지 `@nanonets/graft`의 신원, 게시된 버전 및 Node 요구 사항을 확인하세요.

애플리케이션 종속성 외부, 적절한 위치에 설치하세요.
Graft 설치를 위해 package.json 또는 프로젝트 잠금 파일을 수정하지 마세요.

첫 실행과 MCP에서 `DO_NOT_TRACK=1`을 적용하세요.
가능하면 공식 텔레메트리 비활성화 명령을 사용하세요.

Brain, 계정, LLM 강화 또는 `--deep`을 활성화하지 마세요.
검증 없이 네트워크 제로를 약속하지 마세요.

자동으로 `graft init`을 실행하지 마세요.
명시적 연결을 선호하세요; 설치 관리자가 저장소 외부에 쓸 수 있습니다.

### 진정으로 작동하는 LSP

애플리케이션 코드를 탐색하기 전에 저장소의 Graft 규칙을 준수하세요.
그런 다음 유용한 언어를 식별하고 선택한 Graft 버전의 LSP 통합을 참조하세요.

이미 존재하는 호환 서버를 재사용하세요.
필요한 서버만 설치하고, 버전을 기록하며,
가능하면 애플리케이션 종속성 외부에 설치하세요.

다음을 확인하세요:

- 실행 파일 및 버전;
- Graft/MCP 프로세스의 PATH 내 가용성;
- 언어 및 작업 공간 전제 조건;
- 해당 Graft 버전의 지원 여부.

도움말을 읽은 후, 다음 옵션이 있으면 특히 사용하세요:

    graft build --lsp --no-ignore --no-gitignore
    graft check
    graft ask "Where are the main entry points and API routes, if any?" --source

현재 셸 구문으로 DO_NOT_TRACK을 이 명령들에 적용하세요.

옵션의 의미를 확인하세요: 일부 버전에서는
`--no-ignore`와 `--no-gitignore`가 제외 파일 작성을 방지하며;
이는 "무시된 파일 인덱싱"을 의미하지 않습니다.

선택한 범위에 따라 `/graft/`의 Git 제외를 명시적으로 관리하세요.
Git으로 확인하세요. 이미 추적 중인 파일을 자동으로 제거하지 마세요.
주석과 사람의 내용을 보존하세요.

`--lsp` 빌드와 종료 코드 0이 LSP 사용을 증명하지 않습니다.
목표 증거를 찾으세요: 실제로 시작된 서버, 해석 결과,
강화된 엣지 또는 문서화된 진단.

언어별로 보고하세요:
LSP 확인됨 / 관찰된 강화 없이 사용 가능 / 사용 불가 / 지원 안 됨.

전체 그래프나 wiring.json을 컨텍스트에서 절대 로드하지 마세요.
자동 새로 고침 후에도 LSP 강화가 지속되는지 확인하세요;
보장되지 않으면 명시적 재구성이 필요함을 문서화하세요.

### MCP 및 최신 상태

클라이언트별로 단일 유효 Graft 진입점을 구성하세요.
실제로 지원되는 파일, 스키마 및 범위를 발견하세요.

각 서버에 대해 다음을 확인하세요:
설치된 명령, MCP 인수, DO_NOT_TRACK, PATH 및 작업 디렉터리.

`.kimi-code/mcp.json`, `.mcp.json` 또는 기타 파일이 자동으로 로드된다고 가정하지 마세요: 클라이언트 메커니즘 또는 필요한 실행 옵션을 확인하세요.

대상 프로세스가 각 저장소를 올바르게 처리하는 경우에만 전역 MCP 구성이 허용됩니다.
그렇지 않으면 MCP를 프로젝트 수준에 유지하세요.

매번 시작 시 `npx -y ...@latest`를 사용하지 마세요.
절대 개인 경로나 비밀을 버전 관리하지 마세요.
범용 변수 `${workspaceFolder}`를 임의로 만들지 마세요.

이 프로필에서는 Graft 훅을 추가하지 마세요.
스마트 그렙, 그렙 리디렉트 또는 Graft 셸 가로채기 없음.

새로 고침과 의도치 않은 비활성화 부재를 확인하세요.
새로 고침 실패는 그래프를 최신으로 표시하는 것을 금지합니다.

마이그레이션 전에 오래된 통합 및 자동 연결 메타데이터를 검사하세요.
식별되고 백업된 요소만 제거하세요.
MCP 시작 및 쿼리 후 다시 나타나지 않는지 확인하세요.

### Graft 통계

작업, 관찰된 사용 및 통계 수집을 분리하세요.

버전에 따라 `graft stats`는 세션 훅에 의존합니다.
이 훅이 없으면 성공적인 Graft 요청에도 불구하고 "아직 기록된 세션이 없습니다"라는 메시지가 예상될 수 있습니다.

통계를 조작하거나 이 메시지를 없애기 위해 `graft init`을 실행하지 마십시오.

사용자가 네이티브 통계를 요구하는 경우, 사용 가능한 측정 훅의 호환성을 노출하고 활성화 전에 훅 없이 프로필 진화를 명시적으로 요청하십시오.

## 6. Ponytail lite

클라이언트와 범위에 호환되는 공식 통합을 선호하십시오.
매니페스트, 이벤트, 의존성을 확인하십시오.

다음을 구분하십시오:
플러그인 설치, 활성화, 기본 모드, 현재 모드 상태.

실제로 읽힌 소스를 검사하십시오:
구성, `PONYTAIL_DEFAULT_MODE`, 영구 상태, 플러그인 데이터.
`defaultMode: lite`는 오래된 전체 상태가 교체되었음을 증명하지 않습니다.

모드가 대화 간에 공유된다면 이를 표시하십시오.
프로젝트 범위에서는 전역 기본값을 조용히 변경하지 마십시오.
문서화된 로컬 메커니즘이나 지침에 따른 lite 정책을 사용하십시오.

클라이언트별:

- Claude/Codex: 사용 가능한 범위에서 공식 설치 및 활성화.
  사용 전에 하위 명령어를 확인하십시오.
  훅 승인 권한은 사용자에게 남아 있습니다.
- Cursor: 공식 어댑터 또는 지침 규칙; 누적을 피하십시오.
  `scripts/cursor-hooks.js install --project`가 존재하면,
  공식 체크아웃 경로를 사용하여 대상 저장소 루트에서 스크립트를 실행하십시오.
  `--project`가 없으면 사용자 대상지를 확인하십시오.
  생성된 경로를 검사하십시오: 개인 체크아웃에 대한 절대 경로를 포함하는 프로젝트 훅은 이식 불가능하며 커밋해서는 안 됩니다.
- Kimi: 호환 가능한 공식 어댑터를 찾으십시오. 그렇지 않으면 AGENTS.md의 lite 정책;
  유용한 경우에만 최소한의 로컬 스킬을 추가하고 그 형식과 로딩이 확인된 경우에만 추가하십시오.
  네이티브 명령이나 통계를 약속하지 않고 적응으로 식별하십시오.
- 기타 선택된 클라이언트: Claude/Codex 이벤트를 자동으로 전환하지 않고 동일한 검증을 적용하십시오.

어댑터 체크아웃은 식별된 버전 또는 커밋에 유지하십시오.
수정된 체크아웃에서 git pull을 하지 마십시오.
상태 표시줄이나 시각적 표시기를 추가하지 마십시오.

새 세션에서 실제 모드를 테스트하십시오.

## 7. 간결한 공통 지침

AGENTS.md에서 다음으로 구분된 블록을 병합하십시오:

    <!-- agent-stack:start -->
    ...
    <!-- agent-stack:end -->

모든 외부 콘텐츠와 사람의 추가를 보존하십시오.
이 설치 프롬프트를 에이전트 지침에 복사하지 마십시오.

블록은 다음을 표현해야 합니다:

### Graft

코드를 이해하거나 수정하려면 먼저 애플리케이션 탐색:
`graft ask "<정확한 질문>" --source` 또는 실제 노출된 MCP Graft 도구.

지침, 스킬, Git, 구성 및 MCP 발견이 선행될 수 있습니다.
방향 설정 후 유용한 부분을 직접 읽으십시오.
호출자에게는 사용 가능한 추적 명령/도구를 사용하십시오.

오래된 그래프의 경우: 확인, LSP로 적응 재구성, 그 다음 새 쿼리.
검색 실패 시: 대상 graft grep, 그 다음 직접 읽기 또는 제한 설명이 있는 rg.

제공된 파일, 스택 트레이스, 구성 또는 인덱스되지 않은 언어는 직접 대상 읽기를 허용합니다.
그래프에 없다고 해서 코드나 호출자가 없다는 증거는 아닙니다.

수정 후: graft blast, 검증된 Git 베이스, 관련 테스트.
--name 없음, 전체 그래프 로딩 없음.
실제 호출 수와 오류를 보고하십시오.

### RTK

검증된 훅: 이중 접두사 없이 재작성 허용.
그렇지 않으면 호환 명령에 명시적 접두사.
Graft를 RTK를 통해 전달하지 마십시오.

전체 출력의 경우: 가능하면 --full 재호출 또는 프록시.
부작용이 있는 명령을 자동으로 재실행하지 마십시오.
파이프라인과 리디렉션을 보존하십시오.

검증 전: 실제 압축 해제된 diff, diff --cached, diff --check 및 새 파일 별도 검사.
자동 스테이징 없음.

### Ponytail lite

요청을 올바르게 구현하고 기존 것을 재사용하십시오.
상당히 단순한 솔루션을 간략히 보고하십시오.
검증, 보안, 권한, 접근성, 트랜잭션 및 필요한 테스트를 보존하십시오.
삭제 또는 인라인 전에 사용을 확인하십시오.

명시적 요청 시에만 전체, 기본값으로는 절대 초경량.
감사는 재설계를 촉발하지 않습니다.
보안, 파서, 동시성, 마이그레이션에 대해 수정이 우선입니다.

공유 모드가 대화에 국한되었다고 주장하지 마십시오.
권한 있는 전체 후 lite로 복귀를 확인하십시오.
Off는 이미 주입된 지침을 제거하지 않습니다.

### 로딩

각 클라이언트가 실제로 이 지침을 어떻게 로드하는지 확인하십시오.
문서화된 최소 임포트/어댑터를 사용하십시오.
중복 및 순환 임포트를 피하십시오.

RTK는 유일한 셸 재작성기입니다.
이 프로필에 Graft 훅 없음.

## 8. 업데이트 및 수리

동일한 프롬프트는 중복 없이 다시 실행할 수 있어야 합니다.

업데이트 모드에서:

1. 범위 선택과 이전에 검증된 상태를 다시 읽습니다.
2. 설치된 버전, 대상 버전, 호환되지 않는 변경 사항을 비교합니다.
3. 마이그레이션 전에 백업합니다.
4. 선택된 구성 요소만 업데이트합니다.
5. 공식 메커니즘으로 플러그인/어댑터를 새로 고칩니다.
6. 기능을 재평가합니다: 이전 폴백이 이제 동일 범위 내에서 네이티브 통합으로 대체될 수 있습니다.
7. 이 스택에 속한 키와 블록만 마이그레이션합니다.
8. 필요 시 그래프를 재구축하고 LSP를 재검사합니다.
9. 필요한 MCP/클라이언트 프로세스를 재시작합니다: 기존 프로세스가 여전히 이전 버전을 실행 중일 수 있습니다.
10. 수정된 통합의 검사 및 테스트를 재실행합니다.

이미 호환되는 구성 요소를 불필요하게 재설치하지 마십시오.
머신 패키지의 일반 업데이트를 실행하지 마십시오.

수리 모드에서는 입증된 비호환성과 명시적 업데이트 결정 제외하고 버전을 유지하십시오.

대상 롤백을 준비하십시오: 이전 버전, 백업, 정확한 명령.
백업 이후 다른 변경이 발생했다면 파일 전체를 무작정 복원하지 마십시오.

요청된 변경 없이 두 번째 실행은 훅, MCP 서버 또는 중복 지침 섹션을 생성해서는 안 됩니다.

## 9. 검사 및 증거

별도로 테스트하십시오:

- RTK 실행 가능 및 명시적 압축;
- 자동 훅 트리거링, 제외 및 원시 패스스루;
- Graft: 최신성, 저장소와 일치하는 결과, LSP 보강;
- MCP: 기능적 서버 및 각 클라이언트에서 실제 로딩;
- Ponytail: 활성화 및 효과적인 모드;
- 중복 및 재발된 자기 연결 부재;
- 구성의 최종 유효성 및 효과 범위.

현재 파일은 로딩의 증거가 아니다.
외부 MCP 프로브는 클라이언트 내 로딩의 증거가 아니다.
명시적 RTK 접두사는 자동 훅의 증거가 아니다.

사용 가능하고 인증된 각 클라이언트에 대해 저장소에서 새로운 세션을 열고
일반적인 보호 조치를 적용한 후 이 중립 티켓을 제공하라:

"코드를 수정하지 않고 주요 진입점을 찾으시오.
API가 있다면 경로가 어디에 마운트되는지 표시하고
비즈니스 로직으로 가는 경로를 추적하시오. 파일과 라인을 인용하시오."

"use Graft"를 추가하지 마시오.
내부 추론이 아닌 보이는 도구 호출을 검사하시오.
최소한의 증거를 유지하고 민감한 데이터는 편집하시오.

승인, 로그인 또는 UI 동작이 없으면:
테스트되지 않음 / 사용자 동작, 성공을 가정하지 마시오.

## 10. 납품물

허가된 범위 내에서 짧은 유지보수 문서를 유지하시오:

- 운영 선택, 클라이언트 및 범위;
- 정확한 버전, 출처 및 검증 날짜;
- 구성 메커니즘 및 한계;
- Graft/LSP 재구성;
- 업데이트, 검증 및 롤백 절차.

공유 설치의 경우 `docs/agent-stack.md`를 사용하시오.
개인/전역 설치의 경우 버전 관리 파일에 머신별 정보를 포함하지 마시오.
검증 전용 모드에서는 이 파일들을 생성하지 않고 보고서를 제출하시오.

결정적인 명령, 결과, 수정된 파일,
백업 및 정확한 사용자 동작을 보고하시오.

최종 훅을 목록화하시오:
클라이언트, 출처, 범위, 이벤트, 매처, 역할 및 편집된 명령.

다음으로 마무리하시오:

클라이언트/버전 | 효과 범위 | 현재 구성 |
MCP 로드됨 | 최초 탐색 시 관찰된 Graft |
LSP | RTK | Ponytail | 남은 증거/동작

명시적 상태를 사용하시오:
CONFIGURED / LOADED / USAGE OBSERVED / NOT TESTED / BLOCKED / NOT APPLICABLE.

파일 분류:
검토 후 커밋 대상 / 무시 대상 / 머신 구성.

개인 경로, 비밀, 캐시, 그래프, 백업 및 기록은
커밋할 파일에 포함되어서는 안 된다.

최종 Git 상태와 이 개입으로 도입된 변경 사항을 표시하되,
기존 변경 사항과 구분하시오. 아무 것도 커밋하지 마시오.

태그