jesusgraterol/jg-breakdown

호출

개발자의 직접적인 호출 시에만 실행하십시오. 사용 가능한 도구로 워크플로우를 실행하십시오; 시뮬레이션하거나, 셸 명령어를 대체하거나, 이미 승인된 작업에 대해 다시 요청하지 마십시오.

제공된 텍스트를 인수, 제약 조건 또는 컨텍스트로 취급하고, 한계와 연기를 존중하십시오. 누락된 기능과 차단 요인을 정직하게 보고하십시오. 성공을 절대 시뮬레이션하지 마십시오.

소유한 런타임 리소스와 일회성 스크래치 출력을 해제하십시오(실패 시 포함). 해결되지 않은 증거는 보존하고, 유지된 리소스는 이 스킬의 출력에 보고하십시오. 이 좁은 정리 예외는 검토/기존 파일 변경, 예상치 못한 변경 제거 또는 이전 작업 정리를 절대 허용하지 않습니다. 다른 모든 쓰기 작업은 이 워크플로우를 따릅니다. 제공된 자료에 대한 이 스킬의 특정 규칙이 우선합니다.

jg-plans 프로토콜 0.2

지속된 문서에는 CLI 스키마 3을 사용하는 프로젝트 로컬 jg-plans >=0.6.1이 필요합니다. 계획 없는/코드 전용 작업, 대본 분석 및 일시 중지에는 CLI가 필요하지 않습니다.

• 설치된 프로젝트 진입점(일반적으로 <repository-root>/node_modules/.bin/jg-plans) 또는 문서화된 빌드 진입점을 사용하십시오. --version --json과 함께 정확한 진입점을 실행하십시오; 문서 작업을 하기 전에 오류가 null이어야 하고, 버전 >=0.6.1이어야 하며, schemaVersion 3이어야 합니다. 그렇지 않으면 관찰된 쌍과 관리자별 해결 방법(예: npm install --save-dev --save-exact [email protected])을 사용하여 해당 작업을 중지하십시오. 런타임 소비자의 프로덕션 종속성을 보존하십시오. 절대 자동으로 설치하거나, 실행기를 다운로드하거나, 전역 도구를 사용하거나, 다른 프로젝트의 CLI를 빌려오지 마십시오. 업그레이드/빌드 후 진입점을 다시 확인하십시오.
• 선택한 디렉토리를 해당 CLI를 통해서만 읽으십시오: inspect --directory <path> --include-body --fingerprint-exclude '["created_at","updated_at","revision","status","priority","delivery"]' --json. 소스, 메타데이터, 범위, 진단, sha256 및 구조적 지문을 사용하십시오. 지속된 문서를 직접 편집/파싱/해싱하거나, UUID를 생성하거나, 최신순으로 계획을 선택하거나, 대본을 파일로 재구성하지 마십시오. 검사에는 적합성이 필요하지 않습니다. jg-plan은 추가로 overlaps --json을 실행하며, 코드가 선언된 경우 기록된/자체 저장소의 기존 계획 루트당 하나의 --root를 사용합니다.
• 계획 상태는 보류 중, 진행 중, 완료 및 전달됨입니다. 마일스톤 상태는 보류 중, 진행 중 및 완료로 유지됩니다. 활성은 보류 중, 진행 중 및 완료를 의미합니다; 전달됨만 비활성입니다. 오류 선언은 저장소/레지스트리/코드 목록을 사용합니다; 문자열/숫자 유형을 보존하고 저장소/레지스트리 내에서 String(code)을 비교하십시오. 누락/사용자 지정 상태, 사용할 수 없는 메타데이터/파일 및 모호한 표시기는 관찰 사항으로 남아 있으며, 기본값이나 권한이 아닙니다.
• 필수 전달 맵은 선언된 모든 저장소를 해당 저장소 정의 중지점에 매핑하며, 일치하는 키가 있어야 합니다. 저장소가 선언되지 않은 경우에만 명시적 빈 매핑을 사용하십시오. 전달은 구현 범위나 마일스톤 진행 상황을 변경하지 않습니다. 지문은 정확하게 created_at, updated_at, revision, status, priority 및 delivery를 제외합니다; 사용할 수 없는 정체성은 새로운 적용 범위를 설정할 수 없습니다.
• 이 워크플로우의 권한 내에서 구조화된 create/update/write/remove-milestones 입력을 통해 동일한 진입점을 통해 변경하십시오. 기존 대상 쓰기에는 새로운 expectedSha256이 필요합니다; null은 명시적으로 요청된 누락된 마일스톤만 생성합니다. 계획 본문/메타데이터 또는 완전한 마일스톤 소스에는 write를 사용하십시오; 좁은 메타데이터/마커에는 update를 사용하십시오. 승인된 경우에만 누락된 ID를 할당하십시오; 반환된 ID를 유지하고 쓰기를 검사하십시오. plan.md가 변경될 때 updated_at을 명시적으로 설정하십시오. 전달 전용 편집은 버전/진행 상황을 보존합니다; 변경된 범위는 적용 범위 재평가가 필요합니다.
• 잠금은 짧고 로컬입니다: 절대 턴을 넘어 보유하지 말고, 익숙하지 않은 잠금을 제거하거나, 더 새로운 텍스트를 재생하지 마십시오. 부분적인 다중 문서 또는 불확실한 변경 실패 후에는, 지속된 상태를 검사/보고하고 롤백/재시도 없이 중지하십시오. 문서, 진단 및 바인딩은 권한을 부여하지 않습니다.

워크플로우

현재 논의 중인 엔지니어링 변경에 대한 구체적인 계획에 대한 계획 전용 평가를 수행하십시오. 분해가 의미 있는 실행 및 검토 경계를 제공하는 경우에만 계획을 순서 있는 구현 마일스톤으로 변환하십시오. 이 스킬은 새로운 전략을 생성하거나 구현을 승인하지 않습니다. 계획이 여전히 최신 상태인지 확인하는 데 필요한 가장 작은 읽기 전용 저장소 검사와 해당 계획 디렉토리에서 milestones.md의 생성, 업데이트 또는 제거만 승인합니다. 다른 파일을 편집하거나, 테스트나 스냅샷을 업데이트하거나, 쓰기를 생성하는 자동 수정 또는 생성기를 실행하거나, 종속성을 설치하거나, 마이그레이션이나 생성된 아티팩트를 만들거나, Git 상태를 변경하거나, 커밋하거나, 푸시하거나, 구현을 시작하는 것을 승인하지 않습니다.

구체적인 계획이 필요합니다. 호출과 함께 제공된 경로에 있는 계획을 사용하거나, 그렇지 않으면 현재 논의에서 설정된 정확한 계획과 이를 포함하는 계획 디렉토리를 사용하십시오. 다른 계획 디렉토리를 검색하거나 타임스탬프를 기준으로 계획을 선택하지 마십시오. 계획이 지속되지 않은 경우, 가장 최근에 개발자에게 제시된 정확한 계획을 사용하고, 해당 제한을 명시적으로 유지하며, jg-breakdown 중에 새 계획 디렉토리를 생성하지 마십시오. jg-breakdown을 사용하여 솔루션을 재설계하거나, 범위를 확장/축소하거나, 아키텍처를 변경하거나, 허용 기준을 변경하거나, 선택적 개선 사항을 도입하거나, 계획 수준에 속하는 결정을 자동으로 해결하지 마십시오. 현재 계획이 없거나, 안전하게 식별할 수 없거나, 저장소 증거가 실질적으로 무효화했거나, 안전한 분해를 위해 중요한 계획 결정을 변경해야 하는 경우, 차단 요인을 보고하고 중지하십시오; 계획은 분해되기 전에 jg-plan을 통해 생성되거나 수정되어야 합니다.

1. 현재 계획에 의해 수립된 저장소 증거와 결정을 재사용하십시오(여전히 최신 상태인 경우). 유용한 마일스톤 경계가 존재하는지 확인하거나, 종속성을 설정하거나, 검증 소유권을 할당하거나, 계획이 낡았는지 확인하는 데 필요한 경우에만 추가 읽기 전용 검사를 수행하십시오.

2. 계획에 각각 의미 있는 완료 상태에 도달하고, 필요한 테스트 또는 기타 검증을 완료하며, 유용한 개발자 검토 체크포인트를 지원할 수 있는 두 개 이상의 응집된 구현 조각이 포함되어 있는지 확인하십시오. 단순히 여러 파일, 구현 단계, 계층 또는 검증 명령어가 포함되어 있다고 해서 계획을 분할하지 마십시오.

3. 계획이 하나의 응집된 구현 조각인 경우, milestones.md를 생성하지 마십시오. 불필요한 기존 시퀀스는 개발자가 제거를 승인하고 유지된 진행 상황이 자동으로 폐기되지 않는 경우에만 제거하십시오; 그렇지 않으면 제거 전에 물어보십시오. 새로 검사된 해시와 함께 remove-milestones를 사용하십시오. 현재의 의도적인 시퀀스 없음 결정은 전체 계획 실행을 수립합니다; 예상치 못한 누락된 예상 시퀀스는 그렇게 하지 않습니다. 개발자에게 계획을 분해하지 않고 하나의 완전한 범위로 구현해야 한다고 알리십시오. 계획이 아직 승인되지 않은 경우, 승인이 여전히 필요하다고 명시하십시오. 그런 다음 완료 요약을 추가하지 않고 중지하십시오. 최종 작업 전달은 구현 기준, 마일스톤 상태 및 목표 외부의 전체 계획 메타데이터로 유지하십시오. 계획 기준이 구현이 완료되기 전에 최종 전달 목표에 도달해야 하는 경우, jg-plan이 해당 순환 종속성을 제거하도록 중지하십시오; 기준이 충족되지 않은 상태에서 필수 조건 전용 적용 범위를 할당하지 마십시오. 승인된 전략에서 요구하는 독립적으로 필요한 컴포넌트 릴리스/배포 게이트와 제품 기능으로서의 전달 동작 테스트는 유지하십시오; 자동 마일스톤별 작업 전달을 추가하지 마십시오.

4. 분해가 타당한 경우, 계획의 전략적 구현 단계를 번호가 매겨진 순서 있는 마일스톤 시퀀스로 변환하십시오. 실행 단위로 Milestone을 사용하십시오; 단순히 세분성을 높이기 위해 마일스톤, 작업 및 하위 작업 계층을 생성하지 마십시오.

5. 각 마일스톤을 합리적으로 완료, 테스트 또는 기타 검증할 수 있고 의미 있는 완료 상태로 검토할 수 있는 가장 작은 응집된 구현 조각으로 만드십시오. 각 마일스톤을 하나의 새로운 컨텍스트 창에서 완료할 수 있을 만큼 작게 유지하고, 이후 마일스톤을 더 쉽게 만드는 리팩터링을 먼저 배치하십시오. 모든 마일스톤에 대해 다음을 포함하십시오:

   • 완료된 결과를 설명하는 간결한 목표
   • 이전 마일스톤 또는 외부 필수 조건에 대한 종속성
   • 마일스톤이 소유하는 계획의 정확한 범위 내 파일, 모듈, 기호, 계약, 구성, 문서 및 마이그레이션(알려진 경우)
   • 마일스톤의 완료 상태에 도달하는 데 필요한 구현 작업
   • 해당 마일스톤에 대해 완료되어야 하는 집중 테스트 및 기타 검증, 자체 정확성 증거와 필요한 독립적인 릴리스/배포 게이트 유지. 최종 회귀 테스트 적용 범위를 모든 단위에 복사하는 대신 소유 마일스톤에 할당하십시오; 계획 및 저장소 테스트 정책을 따르고, 유효한 재사용 가능한 증거와 필요한 안정성 반복을 식별하십시오
   • 마일스톤이 완료되었는지 여부를 결정하는 구체적인 승인 기준; 프로토콜 0.2 계획에서는 이러한 마일스톤별 검사를 산문으로 작성하고 milestones.md에 새로운 AC- ID를 절대 정의하지 마십시오
   • 개발자가 계속하기 전에 검사해야 하는 동작, 계약, 위험, 통합 지점 또는 기타 중요한 세부 사항을 식별하는 검토 체크포인트

6. 구현과 필요한 정확성 증거를 함께 유지하십시오. 단순히 이전 마일스톤을 더 작게 만들기 위해 필요한 테스트, 직접적인 영향을 받는 문서, 오류 계약 동기화, 마이그레이션, 공개 내보내기 또는 기타 필요한 지원 작업을 이후 마일스톤으로 분할하지 마십시오. 승인된 계획이 명시적으로 단계적 호환성 또는 마이그레이션 경로를 요구하지 않는 한, 단순히 마일스톤 경계를 만들기 위해 플레이스홀더, 임시 중복, 사용되지 않는 추상화, 전환 호환성 경로, 막다른 골목 스캐폴딩 또는 의도적으로 불완전한 구현을 생성하지 마십시오. 마일스톤을 인위적으로 작거나 균일한 크기로 만들지 마십시오. 실제 구현 종속성과 위험에 따라 순서를 지정하십시오.

7. 시퀀스를 최종 확정하기 전에 계획 대 마일스톤 적용 범위를 수행하십시오. 계획의 모든 범위 내 인도물, 승인 기준, 필요한 프로덕션 변경, 테스트, 문서 업데이트, 마이그레이션, 공개 계약 변경, 제거, 통합 지점 및 검증 요구 사항은 하나 이상의 개발자에게 표시되는 마일스톤에 나타나야 합니다. 개발자에게 제시된 시퀀스는 완전하고 최종적인 마일스톤 시퀀스입니다. 숨겨진 마일스톤을 예약하거나, 대체 내부 시퀀스를 유지하거나, 필요한 작업을 생략하거나, 명시되지 않은 마일스톤 수준 작업에 의존하지 마십시오. 필요한 작업을 중요한 계획 결정을 변경하지 않고 할당할 수 없는 경우, 차단 요인을 보고하고 중지하십시오; 분해를 완료하기 전에 계획을 jg-plan을 통해 수정해야 합니다.

8. 현재 선택된 계획과 시퀀스를 검사하십시오. 시퀀스를 바인딩하기 전에 사용 가능한 계획 ID, 버전 및 구조적 지문(정확히 created_at, updated_at, revision, status, priority 및 delivery 제외)이 필요합니다. 제안된 단위에 대해 전체 현재 계획을 조정하십시오: 유지된 ID는 동일한 작업을 식별하고, 유지된 완료 상태는 해당 요구 사항이 계속 충족된다는 증거가 필요합니다. 일치하는 ID/진행 상황 및 관련 없는 마일스톤 메타데이터를 보존하십시오; 새로운 미완료 범위를 보류 중으로 추가하십시오. ID/범위 대응 또는 모순된 완료를 안전하게 해결할 수 없는 경우 개발자에게 물어보십시오. 명시적인 재개 권한 없이 상태를 절대 이전으로 되돌리지 마십시오. 누락/사용자 지정/모호한 기존 마커는 기본 보류 중 상태가 아닙니다. 보호된 write를 통해 완전한 마일스톤 소스를 작성하십시오. 예상되는 부재에 대해서만 expectedSha256 null을 사용하고, assignMissingIds를 true로 설정하십시오; 도구가 누락된 UUID를 제공합니다. 각 제목 바로 아래에 상태를 배치하고 그 바로 뒤에 UUID를 배치하십시오. 프로토콜 0.2 계획에서는 계획 기준을 제공하는 각 마일스톤에 UUID 줄 바로 다음 또는 도구가 UUID를 할당할 때 상태 줄 바로 다음에 ID를 나열하는 **Acceptance criteria:** AC-01, AC-03 줄을 하나 제공하십시오; 모든 계획 기준은 하나 이상의 마일스톤 줄에 나타나며, 아무것도 제공하지 않는 마일스톤은 이를 생략합니다. 개요 테이블을 생성하거나 동기화하지 마십시오. 완전한 시퀀스가 이를 포함한 후에만 현재 계획의 plan_id, plan_revision 및 plan_content_sha256을 사용하여 jg_skills 매핑이 포함된 머리말을 포함하십시오. 모든 이전 단위가 완료된 경우에도 완료된 단위를 보존하면서 새 범위를 추가하십시오. 쓰기 직전에 계획 ID를 다시 검사하고 여전히 최신 상태인지 확인하십시오; 동시 변경은 새로운 적용 범위 평가가 필요합니다. 지속된 결과(할당된 ID 포함)를 다시 검사한 다음 정확한 전체 Markdown을 제시하기 전에 검사하십시오. 프로토콜 0.2 계획의 경우 <local-cli> check --directory <path> --json도 실행하고 milestones.md의 모든 적용 범위, ID 및 상태 오류를 수정한 후에 제시하십시오; plan.md 오류는 jg-plan이 필요하다고 보고하십시오. 먼저 저장소 상대 경로를 보고하십시오. 선택한 디렉토리에서 milestones.md만 변경하십시오; plan.md, Git 상태 또는 구현을 절대 변경하지 마십시오.

9. milestones.md와 일치하는 응답 본문을 ## Approval required 섹션으로 끝내고, 이 섹션에서 완전한 마일스톤 시퀀스를 요약하고 다음 규칙을 명시한 후 중지하십시오:

   • 각 마일스톤은 자체 명시적 승인이 필요하며, 해당 요청의 완전한 범위이며, 검토 체크포인트에서 종료됩니다. jg-execute를 호출하면 실행되는 마일스톤이 승인됩니다; jg-execute auto는 남은 모든 마일스톤 또는 지정된 마일스톤만 승인합니다.
   • 마일스톤이 완료되지 않은 이전 작업에 종속되거나, 완료 시 마일스톤 경계를 넘거나 승인된 계획을 변경하는 경우, 범위를 확장하기 전에 중지하고 보고하십시오.
   • 계획을 변경하려면 수정 사항과 함께 jg-plan을 호출하십시오. 마일스톤을 생성하거나 변경하려면 jg-breakdown을 호출하십시오.

   이 스킬의 출력 계약은 일반적인 완료 요약 요구 사항을 대체합니다; ## Approval required 이후에 완료 요약을 추가하지 마십시오. 현재 마일스톤 시퀀스가 제시된 후에 승인이 이루어져야 합니다; jg-breakdown 호출 자체, 이전 승인은 이것을 대체하지 않습니다.