Repo-grounded Change은(는) 무엇을 하나요?

기존 프로젝트에 대한 최적화 요청을 확인된 구현 준비 변경 사항으로 전환한 후 승인된 옵션만 실행합니다.

상호작용 및 승인 계약

솔루션을 추천하기 전에 현재 저장소를 검사하십시오. 코드, 테스트, 구성 또는 해당 제품 문서에서 발견 가능한 사실을 사용자에게 묻지 마십시오.
사용자가 옵션이나 수정 기준을 명시적으로 승인할 때까지 읽기 전용 상태를 유지하십시오. 진단 및 저장소 검사는 편집을 승인하지 않습니다.
이 워크플로우를 직접적이고 명확한 구현 요청에 강요하지 마십시오. 사용자가 먼저 평가를 요청하거나 선택이 동작, 호환성, 위험 또는 범위에 실질적으로 영향을 미칠 때 게이트를 사용하십시오.
의사 결정에 필요한 질문만 하십시오. 사용 가능한 경우 구조화된 사용자 입력 컨트롤을 사용하고, 그렇지 않으면 Q1-A와 같은 간결한 옵션 코드를 사용하십시오.
일반적으로 2~3개의 상호 배타적인 실행 가능한 옵션을 제공하십시오. 권장 옵션을 먼저 제시하고 이유를 설명하십시오. 안전한 옵션이 하나만 있는 경우, 가짜 선택지를 만드는 대신 대안이 왜 거부되었는지 설명하십시오.
확인 후, 관련 없는 정리를 조용히 추가하지 않고 선택된 옵션을 구현하십시오. 새로운 저장소 사실이 승인된 동작, 범위, 마이그레이션, 의존성 또는 승인 기준을 실질적으로 변경하는 경우 중단하고 수정된 결정을 요청하십시오.

증거 및 결정 레이블

사실과 해석을 분리하십시오:

사용자 목표: 사용자가 말한 문제점과 결과.
코드 사실: 현재 소스, 테스트, 런타임 또는 구성에서 관찰된 동작.
문서 사실: 해당 승인된 제품 문서에 필요한 동작.
기술 제안: 의도된 제품 동작을 유지하는 구현 권장 사항.
제품 가정: 확인이 필요한 가역적 가정.
미확인: 구현을 방해하는 해결되지 않은 선택.
확인됨: 사용자가 명시적으로 승인한 옵션 또는 기준.
이번에 변경하지 않음: 승인된 변경 범위를 의도적으로 벗어난 동작 또는 코드.

사용자가 달리 지정하지 않는 한, 다음 권한 순서를 사용하십시오:

현재 명시적 사용자 지침.
현재 작업에서 명시적으로 확인된 결정.
해당 승인된 제품 사양.
기존 동작을 위한 현재 코드 및 테스트.
README 파일 및 기록 문서.

충돌을 노출시키고, 조용히 하나의 소스를 선택하지 마십시오.

워크플로우

1. 현재 동작 발견

references/discovery-and-impact.md를 읽으십시오. 문제점을 재현하거나 설명하는 데 필요한 저장소 영역만 검사하십시오. 기존 사용자 변경 사항을 보호하고 적절한 경우 현재 테스트 기준을 수립하십시오.

옵션을 제시하기 전에 현재 동작, 사용자 영향, 관련 코드 경계 및 누락된 증거를 보고하십시오.

2. 변경 목표 명확화

요청을 관찰 가능한 결과와 제약 조건으로 변환하십시오. 옵션, 범위, 호환성 전략 또는 승인 결과를 변경할 수 있는 문제만 명확히 하십시오.

문자 그대로의 UI 단어가 잘못된 상호작용 의미론을 도입할 경우 이를 필수 구현 메커니즘으로 취급하지 마십시오. 차이점을 설명하고 저장소 호환 옵션을 제공하십시오.

3. 실행 가능한 옵션 비교

references/options-and-clarification.md를 읽으십시오. 사용자 경험, 보존된 동작, 상태 및 데이터 호환성, 접근성, 테스트 영향, 구현 노력, 롤백 난이도 및 중요한 위험을 포함한 제품 및 엔지니어링 영향을 비교하십시오.

4. 권장 변경 명세 작성

references/change-spec-and-acceptance.md를 읽으십시오. 권장 옵션은 Codex가 직접 실행할 수 있어야 하며 다음을 포함해야 합니다:

대상 동작 및 상호작용;
영향을 받는 모듈, 컴포넌트, 파일, 인터페이스 및 상태;
관련된 경우 호환성, 영속성, 마이그레이션, 저하 및 롤백 처리;
보존해야 하는 동작 및 데이터;
명시적 제외 사항;
테스트 계획 및 관찰 가능한 승인 기준.

이 단계에서는 코드를 수정하지 마십시오.

5. 명시적 승인 획득

권장 사항과 남은 선택지를 제시하십시오. 사용자가 옵션을 선택하거나 가장 작은 필요한 명확화 라운드에 응답하도록 요청한 후 중단하십시오.

응답 후 확인된 옵션, 사용자 수정 사항, 미해결 문제, 다운스트림 영향 및 최종 승인 기준을 요약하십시오. 응답이 확인, 승인, 동의 또는 명시적 실행 권한을 명확히 부여하는 경우에만 구현을 시작하십시오.

6. 승인된 옵션 구현

더티 워크트리를 다시 확인하고, 관련 없는 변경 사항을 보존하며, 가장 작은 일관된 구현을 만드십시오. 주석은 코드를 다시 설명하는 대신 명확하지 않은 불변성 또는 호환성 결정을 설명해야 합니다.

UI 프리젠테이션이 제거되었다고 해서 기본 도메인 데이터를 삭제하지 마십시오. 삭제가 명시적으로 승인되지 않은 한 삭제하지 마십시오. 유지된 상태, 경로, 스키마 또는 열거형을 변경할 때 저장소에 존재할 수 있음을 나타내는 경우 레거시 값을 처리하십시오.

7. 검증 및 보고

먼저 집중 테스트를 실행한 다음, 적절한 저장소 전체 검사(타입 검사, 린트, 전체 테스트, 빌드, UI 상호작용 또는 시각적 검증)를 실행하십시오. 실행할 수 없었던 검사가 통과했다고 주장하지 마십시오.

구현된 결과, 주요 파일, 검증 증거, 알려진 제한 사항 및 관련 없는 기존 경고를 보고하십시오. 요청된 검증 표면을 사용할 수 없는 경우 공개하고, 승인 없이 명시적으로 선택된 도구 또는 환경을 우회하지 마십시오.

필수 중단 조건

다음 상황에서 중단하고 결정을 요청하십시오:

두 개의 실행 가능한 옵션이 사용자 동작에 실질적으로 다른 결과를 초래하는 경우;
구현에 승인되지 않은 의존성, 통합, 자격 증명, 마이그레이션, 파괴적 작업 또는 비즈니스 규칙 변경이 필요한 경우;
현재 사용자 변경 사항이 필요한 편집과 겹치고 안전하게 보존할 수 없는 경우;
저장소 사실이 승인된 옵션과 모순되는 경우;
승인 기준을 관찰 가능하게 만들 수 없는 경우;
변경을 안전하게 완료하려면 승인된 범위를 확장해야 하는 경우.

어려움, 기간 또는 일반적인 구현 세부 사항은 확인된 결정을 재개하는 이유가 아닙니다.

완료 기준

워크플로우는 선택된 옵션이 범위 내에서 구현되고, 호환성 결정이 처리되고, 승인 기준이 관찰 가능한 증거에 매핑되고, 관련 검사가 실행되었으며, 제한 사항이 정직하게 보고된 경우에만 완료됩니다.

Repo-grounded Change