CSV 가져오기를 만든다고 해 봅시다. 열 하나가 빈 행을 만나면 그 행만 건너뛸까요, 파일 전체를 거절할까요? 구현 세션이 답을 가정하면 코드는 완성돼도 다음 작업자는 그 동작이 합의된 규칙인지 알아내기 어렵습니다. 1.1.0에서는 코드에서 확인할 수 있는 기존 동작과 사람이 정해야 할 새 동작을 구분했습니다. 이어서 작업하는 사람이 같은 판단을 재현할 수 있도록, 빠진 선택을 확인하는 시점과 합의를 기록할 위치도 정했습니다. 1.1.0 변경 근거

코드보다 먼저 남긴 합의

개발 흐름을 요구사항 정리, 구현, 리뷰·검증, 출시의 네 단계로 안내했습니다. 첫 사용자는 단계별로 자주 쓰는 스킬 10개에서 시작하고, 익숙한 사람은 필요한 스킬을 직접 호출할 수 있습니다.

동작을 바꾸는 작업은 합의한 결과와 검증 방법을 명세와 계획에 저장한 뒤 구현합니다. CSV 예시라면 잘못된 행을 건너뛴 뒤 어떤 결과와 오류 정보를 돌려줄지 적는 정도면 됩니다. 충분한 문서가 이미 있다면 그대로 사용하고, 문구만 고치는 작업에는 이 단계를 생략합니다.

구현 직전에는 대표 입력과 기대 결과를 놓고 빠진 결정을 점검합니다. 작업 도중 예상과 다른 제약을 발견하면 제품 동작에 영향을 주는지 확인합니다. 마지막에는 처음 예상한 결과, 실제로 선택한 방식, 달라진 이유를 남깁니다. 기본 단계를 자동으로 이어가기로 한 경우에도 그 범위는 해당 명세까지이며, 원격 푸시 전에 멈춥니다. 단계별 지침

인수인계와 제품 판단의 검증

1.1.0을 준비하며 중단한 작업을 새 세션에서 이어받는 격리 사례와 모호한 요구사항의 협업 비교를 따로 살폈습니다. 인수인계 검사에서는 COCO를 제공한 조건과 스킬 본문을 주지 않은 조건이 모두 기준을 충족했습니다. 협업 비교에서 구현을 완료한 실행은 COCO 조건에서 5건 중 4건, 미사용 조건에서 5건 중 5건이었습니다. COCO 조건의 한 건은 시간 제한에 걸렸습니다. 모호한 요구를 준 실행에서는 두 조건 모두 상품 식별 규칙을 빠뜨려 나중에 코드를 고쳤습니다. 각 비교는 정해진 입력으로 진행했고, 출시 직전에 별도로 계획한 비교 실행 일부는 보류했습니다. 팀의 생산성은 측정하지 않았습니다. 실험과 출시 검증의 범위

예를 들어 상품 코드 A1과 a1을 받으면 공백과 대소문자를 무시해 같은 상품으로 볼지부터 정해야 합니다. 같은 상품이라면 중복 행을 합칠지 거절할지, 내보낼 때 원래 표기를 보존할지도 각각 결정해야 합니다. 그래서 테스트의 기대값을 쓰기 전에 실제 입력과 출력을 놓고 아직 합의하지 않은 선택을 찾도록 구현 지침을 바꿨습니다. 상품 식별과 중복 처리 예시

작업을 이어받는 사람이 다음 결정을 할 수 있도록 합의와 근거를 남기는 일이 1.1.0의 주된 변화였습니다. 1.2.0부터는 그중 공개할 만한 개발 기록을 골라 글로 만드는 흐름도 COCO에 들어갔습니다.