Genesis 프로젝트 작업
Genesis는 설명 및 검증 도우미입니다. 코드베이스, 테스트, Git 리뷰 또는 코딩 에이전트를 대체하지 않습니다.
새 제품 방향 설정
Blueprint가 아직 제품 방향을 설정하지 않은 새 프로젝트의 경우, 사용자가 무엇을 구축 중인지, 누가 또는 무엇이 이를 사용하거나 호출할지, 그리고 첫 번째 관찰 가능한 유용한 결과가 무엇인지 명확히 할 때까지 기술을 조사하거나 소스를 생성하지 마십시오. 해결되지 않은 영향력이 큰 질문만 하십시오. 답변은 명시적으로 답변한 내용만 확인합니다. Stack 확인은 제품 의도가 아닙니다.
제품 방향이 명확해지면, 선택된 기술 가이드 또는 카탈로그에 일치하는 항목이 없을 때 공식 기술 문서를 통해 가장 작은 구현 경로 하나를 선택하고, 해당 경로에 필요한 것만 읽으십시오. 대안을 조사하거나, 전체 기술 저장소를 복제하거나, 관련 없는 패키지 내부를 검사하거나, 하나의 구체적인 실패가 하나의 정확한 조사를 요구하지 않는 한 연구를 위임하지 마십시오.
Genesis 명령 실행
첫 번째 Genesis 작업을 실행하기 전에 호출 방법을 결정하십시오. Genesis 작업 또는 genesis --version을 가용성 프로브로 사용하지 마십시오.
- 저장소 루트의
package.json을 읽습니다. 해당 매니페스트의name이genesis-compiler이거나,dependencies,devDependencies또는optionalDependencies에 정확한genesis-compiler키가 포함된 경우에만 Genesis를 프로젝트 고정으로 취급합니다. - 프로젝트 고정 저장소의 경우, 모든 Genesis CLI 작업을
npm exec --no -- genesis <인수>로 호출합니다. 이렇게 하면 다른 패키지를 가져오지 않고 실행됩니다. 선언된 패키지가 설치되지 않은 경우, 프로젝트의 종속성이 준비되지 않았다고 보고하고, 다른 Genesis 버전으로 대체하지 마십시오. - 그렇지 않은 경우,
npm exec를 시도하지 마십시오.command -v genesis(또는 현재 셸의 동등한PATH조회)를 실행합니다. 실행 파일을 찾으면genesis <인수>를 직접 호출합니다. - 두 소스를 모두 사용할 수 없는 경우 중단하고 Genesis를 사용할 수 없다고 보고하십시오. 단지 워크플로 지침을 충족시키기 위해 Genesis를 설치하거나 업데이트하지 마십시오.
성공적인 호출 결정은 일상적인 작업입니다. Genesis가 프로젝트에 고정되었는지 또는 PATH에 있는지 설명하지 말고, 직접 PATH 사용을 대체 방법으로 설명하지 마십시오. 호출이 선택된 방법은 해결에 실패하거나 사용자가 명시적으로 요청한 경우에만 언급하십시오.
사용자에게 업데이트를 제공할 때는 구성된 협업 방식을 따르되, 기술적 깊이와 응답 길이를 포함하십시오. 구체적인 진행 상황, 발견 사항 또는 차단 요인을 보고하고, 지침을 따르고 있다고 알리지 마십시오.
명시적인 기술 선택 해결
외부 기술 연구 또는 구현 전에, 사용자가 명시적으로 선택되지 않은 기술, 프레임워크, 언어 또는 데이터베이스를 언급하는 경우:
- 첫 번째 기술 작업으로 Genesis
stack list작업을 실행합니다. - 카탈로그 구성 요소 중 하나가 선택 항목과 정확히 일치하면 다음과 같이 질문합니다: "<기술>은 Genesis에서 사용할 수 있습니다. 이 프로젝트에 추가하고 공식 가이드라인에 따라 앱을 준비할까요?" 확인 없이
stack add <piece...>를 실행하지 마십시오. - 확인되면 구성 요소를 추가하고, Genesis가 선언된 종속성 폐쇄를 적용하고 해당 구성 요소가 선언한 권위 있는 Agent Skill을 동기화하도록 합니다. 동일한 작업에서
stack add가 반환한 준비 프롬프트를 따릅니다: 구체화된 각 프로젝트 계약을 참으로 만들거나, 전체 섹션을 증거가 있는 현실로 대체합니다. 그런 다음context .또는 소스가 존재하는 경우 관련 소스 경로를 실행하고, 해당하는 설치된 스킬이 있으면 로드한 후 해당 기술 소유의 지침에 따라 실제 프로젝트 종속성을 준비합니다. 구성 요소 ID에서 설치 명령을 유추하지 마십시오. - 거부되면 구성 요소를 추가하지 않고 계속 진행하며 다시 묻지 않습니다. 카탈로그 구성 요소가 일치하지 않으면 임의로 만들지 말고, 해당 기술이 소유한 공식 문서를 사용하여 정상적으로 계속 진행합니다.
컨텍스트 구축
genesis/blueprint.md를 읽어 비기술적 제품 의도를 파악합니다.genesis/engineering.md를 읽어 선택된 엔지니어링 프로필과 프로젝트별 요구 사항을 파악합니다.genesis/stack.md를 읽어 선택된 기술 구성, 리소스 및 검증 명령을 파악합니다.- 요청에 포함된 소스를 찾습니다.
- 헬퍼나 공개 작업을 추가하기 전에 Genesis
index <이름-또는-경로>작업을 실행합니다. 동작을 이미 소유하고 있는 기존 함수가 있으면 재사용합니다. - 관련 Program 설명과 선택된 Stack 컨텍스트에 대해 Genesis
context <path...>작업을 실행합니다. .agents/skills/또는 에이전트 자체에 설치된 스킬 카탈로그에서 해당 기술 스킬을 로드합니다.
기존 애플리케이션의 첫 번째 Stack 선택의 경우, 구체화된 구성 요소 제안을 수락하기 전에 실제 설정, 빌드 및 출력 명령을 검사합니다. 선택된 구성 요소는 현재 기반을 설명하며, 기존 소스를 조용히 이식하지 않습니다. 기존 명령이 다른 경우, 구현을 변경하지 않고 유지하고 프로젝트 소유의 소비자 작업(예: 호스트의 ## 워크스페이스 설정 또는 ## 출력) 전체를 대체합니다. Genesis는 해당 섹션을 불투명 텍스트로 취급합니다. 명명된 소비자만이 그 의미와 실행을 소유합니다. 제안된 레시피가 소스와 일치할 때까지 사용 가능하다고 주장하지 마십시오.
Program은 간결하고 오류 가능성이 있는 설명입니다. 그 Sources와 선택적 Implementation 맵은 탐색을 돕지만 코드, 테스트 및 런타임 동작을 읽는 것을 대체하지 않습니다.
.genesis/machine-city.json은 파생된 상세 파일/함수 맵입니다.
.genesis/program-city.json은 파생된 더 간단한 서브시스템/작업 맵입니다.
둘 다 권위 또는 증거가 아닙니다. 둘 다 git-ignored이며 Genesis index 작업으로 다시 생성할 수 있습니다.
일반적인 로컬 작업 구현
- Genesis가 제공하는 효과적인 엔지니어링 접근 방식을 적용합니다. 모든 변경 사항은 추론하기 쉬워야 하며 알려진 요구 사항을 완전히 충족하는 가장 작은 대상 구현이어야 합니다. 과도하게 엔지니어링하거나 복잡하게 만들지 말고, 추상화, 계층, 종속성, 인프라, 호환성 경로, 분산 패턴, 암호화 또는 기타 고급 메커니즘을 투기적으로 추가하지 마십시오.
- 구체적인 요구 사항이 필연적으로 복잡성을 요구할 경우, 작성하기 전에 중단하십시오. 직접적인 설계가 왜 불충분한지와 제안된 가장 작은 추가 복잡성을 설명한 다음, 사용자에게 승인을 구하거나 절충점을 명확히 하십시오. 엔지니어링 접근 방식을 조용히 무시하지 마십시오.
- 현재 Git 트리에서 직접 작업하고 일반적인 diff에 유용한 편집 내용을 표시하십시오.
- 구현이 의도적으로 관찰 가능한 제품 동작을 변경하는 경우, 동일한 작업에서 Blueprint와 영향을 받는 Program 모듈을 정렬된 상태로 유지하십시오. 비공개 리팩토링은 수정된 Sources 또는 정보 제공용 Implementation 맵만 필요할 수 있으며 설명 편집이 필요하지 않을 수 있습니다. 구현이 의도적으로 해당 명령이나 기능을 변경하는 경우, 호스트의
## 출력과 같은 정확한 소비자 소유 작업 선언을 정렬된 상태로 유지하십시오. 거기에는 기능 메타데이터와 환경 변수 이름만 기록하고, 값이나 비밀은 기록하지 마십시오. 섹션을 Genesis 동작으로 유추하거나 실행하지 마십시오..genesis/는 교체 가능한 파생 탐색 데이터로 취급하고, 작성된 제품 의도로 취급하지 마십시오. - 병렬 프레임워크, 지속성 계층, 전송, 유효성 검사기 또는 UI 시스템을 만드는 대신 기존 프로젝트 및 기술 경계를 따르십시오.
- 사용할 수 없는 외부 리소스 값을 만들거나 리터럴 환경 변수 이름을 데이터로 전달하지 마십시오. 누락된 리소스를 보고하고 유용한 작업을 유지하십시오.
- 구현을 직접적이고 응집력 있게 유지하십시오. 제공된 Stack 사후 변경 지침이 있으면 완료를 보고하기 전에 적용하십시오. 이는 이 구현 작업의 일부이지, 다른 에이전트 작업에 대한 요청이 아닙니다. 유용한 경우 집중된 검사를 실행하십시오.
검증 및 보고
구현 중에 변경 사항과 관련된 검사를 선택하십시오. 프로젝트의 검증 정책이나 사용자의 요청에 따라, 선택된 기술의 워크스페이스 기반이 존재한 후 Genesis verify를 통해 Stack이 선언한 최종 검사를 실행하십시오. 항목을 완료하거나 세션을 재개한다고 해서 광범위한 검증 실행이 필요한 것은 아닙니다. 전체 출력을 로컬 아티팩트에 보관하고, 종료 상태를 유지하며, 로그를 확장하기 전에 요약과 관련 실패 발췌문을 읽으십시오. 시간이나 토큰을 절약하기 위해 어설션을 약화시키거나 필요한 범위를 생략하지 마십시오. 구성되지 않은 결과는 선언된 워크스페이스 또는 검사가 아직 존재하지 않음을 의미합니다. 실패한 검사가 아닙니다. 완료를 보고하기 전에 요청된 관찰 가능한 동작, 필요한 입력 및 리소스, 선언된 프로젝트 작업, 집중된 증거를 실제 존재하는 것과 비교하십시오. 변경된 파일, 실제로 실행된 검사, 입증되지 않은 사항 및 여전히 주의가 필요한 사항을 보고하십시오. 실행되지 않은 검사가 통과했다거나 통과된 검사가 전체 제품을 증명한다고 주장하지 마십시오.
서브시스템 유지 관리
변경 사항이 서브시스템 책임, Program 멤버십 또는 데이터 소유권/사용을 추가, 제거 또는 변경하는 경우, 동일한 구현 작업에서 genesis/subsystems.md를 유지 관리하십시오. 관련 코드를 변경하기 전에 맵을 읽으십시오. 뚜렷한 책임이 입증되지 않는 한 기존 서브시스템을 재사용하십시오. 서브시스템당 하나의 Source Directory가 필요하며 각 Program 모듈을 정확히 한 번 선언하십시오. Program 폴더 이름은 멤버십을 결정하지 않습니다. 테이블 참조를 스키마/마이그레이션에 근거하십시오. Genesis는 데이터베이스를 검사하지 않습니다. 비공개 헬퍼 변경은 이러한 연결이 변경되지 않은 경우 맵 편집이 필요하지 않습니다.
genesis/subsystems.md가 없거나 기존 설명된 애플리케이션에서 비어 있는 경우, 구현 전에 실제 소스, 스키마 및 기존 Program에서 생성하십시오. 이는 일반적인 설명적 채택이며 차단 요인이나 다시 허가를 요청할 이유가 아닙니다. 기존 Program과 소스를 보존하고, 관련 책임을 검사하여 가장 작은 진실된 맵을 완성하십시오. 초기화는 빈 파일을 생성할 수 있지만, 에이전트만이 그 의미를 작성합니다.