Deslop 에이전트 정리

Genesis Deslop

선택된 변경 사항을 제품 동작 변경 없이 검토하고 단순화합니다. Deslop은 명시적입니다: 구현이 완료되었다는 이유만으로 실행하지 마십시오.

첫 번째 Genesis 작업을 실행하기 전에 호출 방법을 결정하십시오. Genesis 작업이나 genesis --version을 가용성 확인 용도로 사용하지 마십시오.

1. 저장소 루트의 package.json을 읽습니다. 매니페스트의 name이 genesis-compiler이거나, dependencies, devDependencies, 또는 optionalDependencies에 정확히 genesis-compiler 키가 포함된 경우에만 프로젝트를 프로젝트-핀(pinned)으로 취급합니다.
2. 프로젝트-핀 저장소의 경우, 모든 Genesis CLI 작업을 npm exec --no -- genesis <인수>로 호출합니다. 이렇게 하면 다른 패키지를 가져오지 않고 실행됩니다. 선언된 패키지가 설치되지 않은 경우, 프로젝트의 종속성이 준비되지 않았다고 보고하고 다른 Genesis 버전으로 대체하지 마십시오.
3. 그렇지 않은 경우, npm exec를 시도하지 마십시오. command -v genesis(또는 현재 셸의 PATH 조회 방식)를 실행합니다. 실행 파일이 확인되면 직접 genesis <인수>를 호출합니다.
4. 두 소스를 모두 사용할 수 없는 경우, 중단하고 Genesis를 사용할 수 없다고 보고합니다. 단지 워크플로우 지침을 충족시키기 위해 Genesis를 설치하거나 업데이트하지 마십시오.

성공적인 호출 확인은 일상적인 작업입니다. Genesis가 프로젝트-핀인지 PATH에 있는지 설명하지 말고, 직접 PATH 사용을 대체(fallback)라고 설명하지 마십시오. 호출 방법이 선택된 방식은 확인에 실패했거나 사용자가 명시적으로 질문한 경우에만 언급하십시오.

사용자 대상 업데이트에는 설정된 협업 접근 방식을 따르되, 기술적 깊이와 응답 길이를 준수하십시오. 구체적인 진행 상황, 발견 사항 또는 차단 문제를 보고하고, 지침을 따르고 있다고 알리지 마십시오.

한 번만 유효한 프로젝트 지침 로드

Deslop 요청은 완전한 Genesis 생성 프롬프트로 오거나, 에이전트 세션에서 Deslop과 같은 직접 요청으로 올 수 있습니다.

현재 작업에 이미 GENESIS CONTEXT가 포함되어 있고 그 작업이 deslop인 경우, 직접 계속 진행하십시오. 다른 프롬프트를 생성하지 마십시오.

그렇지 않으면, Git 범위를 결정하기 전에 위의 호출 규칙을 사용하여 Genesis prompt --task deslop 작업을 한 번 실행하십시오. 단순한 Deslop 요청의 경우, 요청 인수를 전달하지 마십시오. 사용자가 개수, 커밋 또는 범위를 지정한 경우, 해당 요청을 안전하게 인용된 하나의 인수로 전달하십시오. 출력된 프롬프트를 동일한 턴에 대한 지침으로 취급하십시오. 다른 에이전트에게 전달하지 말고 다시 생성하지 마십시오. 이 단계는 선택된 스택(Stack)의 기술별 Deslop 지침과 프로젝트 사용자 정의를 아래의 이식 가능한 계약과 결합합니다.

정리 범위 결정

편집 전에 git status --short와 스테이징 및 언스테이징된 차이(diff)를 검사하십시오. 더티(dirty) 작업 트리는 허용되며, 이전 커밋은 필요하지 않습니다. 기존 인덱스(index)와 관련 없는 작업을 유지하십시오. 정리의 전제 조건 또는 일부로 변경 사항을 스테이징, 스태시, 커밋 또는 폐기하지 마십시오.

사용자의 범위를 다음과 같이 결정합니다:

• 명시된 범위가 없으면, 현재 작업(이전 턴 포함)에서 자신의 변경 사항만 선택하십시오. 여기에는 스테이징 및 언스테이징된 편집, 새로 추적되지 않은 파일, 이미 커밋된 작업 변경 사항이 포함될 수 있습니다. 작업 및 편집 기록에서 소유권을 식별한 다음, 현재 소스 및 Git 차이와 대조하여 해당 변경 사항을 확인하십시오. 전체 더티 diff, 최신 커밋 또는 Git 작성자 ID는 소유권을 증명하지 않습니다.
• 사용자 또는 다른 에이전트가 만든 변경 사항(동일 파일의 편집 포함)은 유지하십시오. 소유권을 확인할 수 없으면 어떤 변경 사항을 deslop할지 물어보십시오. 이 작업에 대한 자신의 변경 사항이 없으면 deslop할 것이 없다고 보고하십시오. 최신 커밋이나 다른 사람의 작업을 자동으로 선택하지 마십시오.
• 명시적인 커밋, 첫 번째 부모(first-parent) 개수, 또는 범위는 작성자에 관계없이 기본값보다 우선합니다.
• "마지막 커밋"은 첫 번째 부모에 대한 HEAD를 의미합니다.
• "마지막 N개 커밋"은 해당 N개 커밋 이전의 첫 번째 부모부터 HEAD까지의 순수하게 남아 있는 변경 사항의 합을 의미합니다.
• 명명된 커밋은 첫 번째 부모에 대한 해당 커밋을 의미합니다.
• 명시적인 커밋 범위는 정확히 해당 범위를 의미합니다.
• 루트 커밋은 부모가 없으므로 Git의 루트-차이(root-diff) 형식을 사용합니다.

결정된 변경 사항과 경로, 그리고 해당되는 경우 커밋 ID를 검사하십시오. diff, 현재 소스, 직접 호출 사이트, 관련 테스트, 그리고 영향을 받는 Program 및 Stack 컨텍스트를 검토하십시오. 명시적인 커밋 범위의 경우, 일반적인 작업 트리 diff를 선택된 커밋 diff로 대체하지 마십시오. 현재 소스에 정리를 적용하되 범위 밖의 편집은 유지하십시오. 겹치는 편집을 안전하게 분리할 수 없으면, 저장소가 더티(dirty)라는 이유만으로 차단하지 말고 해당 겹침에 대해 물어보십시오.

정리 계약 적용

작업과 함께 제공된 엔지니어링 접근 방식을 적용하십시오. 이 스킬이 직접 호출된 경우 genesis/engineering.md와 관련 프로젝트 컨텍스트를 읽으십시오. 정리는 복잡성을 줄이거나 유지해야 하며, 선택된 프로필이나 구체적인 요구 사항이 필요로 하지 않는 승인되지 않은 메커니즘을 도입해서는 안 됩니다.

추상화를 도입하거나 통합하기 전에 기존 공개 및 내부 함수를 찾으려면 .genesis/machine-city.json을 참조하거나 Genesis index <name-or-path> 작업을 실행하십시오. 소스와 해당 호출 사이트에서 모든 명백한 중복을 확인하십시오.

선택된 변경 사항의 의도된 동작과 범위 내에서, 반복되는 헬퍼, 명확하지 않거나 추론하기 어려운 코드, 코드베이스의 기존 패턴에 어긋나는 코드를 남겨두지 마십시오. 불필요한 래퍼, 버려진 스캐폴딩, 병렬 프레임워크 플러밍, 추측성 추상화를 제거하십시오. 하나의 명확한 모듈로 충분한 경우 소유권을 통합하십시오. 작은 파일이나 간접 참조를 위해 최적화하지 말고, 주니어 프로그래머도 따라갈 수 있는 작고 명확한 설계를 위해 최적화하십시오.

정리는 두 번째 구현 패스가 아닙니다. 선택된 변경 사항이 정리가 발생할 수 있는 범위를 제한합니다. 파일을 공유한다고 해서 관련 없는 편집이 범위에 포함되거나 해당 파일에서 다른 동작이 허용되는 것은 아닙니다. Deslop은 이미 존재하는 동작을 재구성할 수 있습니다. 동작을 완성, 수정 또는 확장할 수 없습니다. 검토 결과 결함, 누락된 동작, 계약 불일치 또는 테스트 격차가 발견되면 후속 조치(findings)로 보고하고 변경하지 않은 상태로 두십시오. 변경된 경로 내에 있거나 이전 구현과 관련된 것으로 보이더라도 마찬가지입니다. Deslop 중에는 결함을 구현하거나 이를 수용하기 위해 테스트를 변경하지 마십시오.

선택된 스택에서 제공하는 모든 기술별 Deslop 지침을 적용하고, 프레임워크 및 언어 컨텍스트에 대한 해당 공식 기술 스킬을 로드하십시오. 스택 지침은 이 계약을 강화합니다. 동작 보존 경계를 약화시키거나, 선택된 범위를 변경하거나, 관련 없는 구현을 승인할 수 없습니다.

구현 및 테스트 파일을 편집하거나 삭제할 수 있습니다(가장 명확한 동작 보존 정리인 경우). 선택된 소스를 이동하거나 이름을 바꾸는 것이 영향을 받는 Program 인용을 구식으로 만드는 경우, 해당 인용 또는 정보 제공용 구현 맵만 업데이트하십시오. Blueprint나 Program 공개 계약을 변경하여 정리 동작을 정당화하지 마십시오. .genesis/, Git 메타데이터, 종속성 디렉토리, 생성된 빌드 출력, 보존된 마이그레이션 기록 또는 외부 리소스를 편집하지 마십시오. 테스트, 공개 동작 또는 데이터 보장을 약화시키지 마십시오. 두 번째 아키텍처를 생성하거나 관련 없는 재작성을 수행하지 마십시오.

정리는 검토 및 이후 정상 커밋을 위한 일반적인 커밋되지 않은 작업으로 남겨두십시오. 선택된 커밋을 수정(amend)하거나 재작성(rewrite)하지 마십시오. 유용한 경우 집중적인 검사를 실행하십시오. 최종 선언된 검사는 Genesis verify 작업을 통해 계속 사용할 수 있습니다. 결정된 범위와 선택된 커밋 ID, 무엇이 단순해졌는지, 변경된 파일, 실제로 실행된 검사, 그리고 변경하지 않은 후속 조치(findings)를 요약하십시오.