검증할 수 있는 TASK_SPEC

"식당에서 각자 얼마를 내야 하는지 계산하는 계산기를 만들어 주세요." 처음엔 명확해 보이지만, 따져 보기 시작하면 질문이 생깁니다. 똑같이 나눌까요, 아니면 각자 먹은 음식값을 낼까요? 팁은 이미 계산서에 포함되어 있나요? 금액이 사람 수로 딱 나누어떨어지지 않으면 무엇을 보여 줄까요?

Claude Code와 함께 작업 명세를 정리해 보겠습니다. 여러분이 작업을 설명하고 결정을 내리면 에이전트가 파일에 기록하고, 여러분은 그 내용을 확인합니다. 짧은 요청에서 시작해 실제 작업에 사용할 수 있는 TASK_SPEC을 차근차근 만들어 보겠습니다.

"제대로 해 주세요"는 작업 명세가 아닙니다

계산서를 빠르게 나누고 싶었는데 에이전트가 회원 가입과 식당 기록 기능까지 추가했다고 생각해 보세요. 계산서를 저장하려면 서버도 필요해집니다. 브라우저에서 파일 하나만 열면 될 줄 알았는데, 이제 실행 방법을 알아보고 불필요한 기능도 걷어 내야 합니다. 각각은 유용해 보여도 결과물은 처음 생각과 크게 달라졌습니다.

코드 작업에서는 빠뜨린 설명이 실제 파일 변경으로 이어질 수 있습니다. 대략 이런 흐름입니다.

이 흐름은 결정하지 않은 사항이 어떻게 추가 작업으로 이어지는지 보여 줍니다. 에이전트가 다시 물어볼 수도 있지만, 수정하기 전에 모호한 부분을 찾는 편이 낫습니다. 첫 요청부터 방향과 범위를 정해 둘 수 있습니다.

아직 모호한 요청:
식당에서 각자 얼마를 내야 하는지 계산하는 계산기를 만들어 주세요.

조금 더 구체적인 요청:
한 페이지에서 계산서 총액과 인원수를 입력하고,
각자 낼 금액을 확인합니다. 똑같이 나눕니다.
계정, 계산서 기록, 음식별 나누기는 만들지 않습니다.

두 번째 요청도 모든 질문에 답하지는 않습니다. 그래도 첫 요청만으로 만들 수 있었던 여러 다른 제품의 방향은 제외합니다. 이제 에이전트의 도움을 받아 남은 빈틈을 찾고 여러분의 결정을 기록할 수 있습니다.

하나의 파일에 담는 작업 명세

TASK_SPEC은 하나의 작업에 필요한 조건을 기록한 문서입니다. 어떤 결과가 필요한지, 작업 범위는 어디까지인지, 어떻게 확인할지를 적습니다. 보통 프로젝트 폴더에 있는 Markdown 파일 TASK_SPEC.md로 저장합니다. 특별한 형식이나 전용 명령이 있는 것은 아닙니다. 조건을 메시지로 전달할 수도 있지만 파일로 두면 다시 읽고 업데이트하기 편합니다.

TASK_SPEC을 직접 작성할 필요는 없습니다. 에이전트와 함께 내용을 정리하고, 여러분의 결정이 어떻게 기록되었는지 확인하는 편이 쉽습니다. 평소 쓰는 말로 작업을 설명하고, 질문에 답하고, 문장을 고쳐 달라고 요청하면 됩니다. 에이전트가 파일을 관리하고 여러분은 그 의미를 확인합니다.

1. 원하는 결과를 설명하고 모호한 부분을 논의합니다.
2. 에이전트가 선택지를 제안하면 알맞은 것을 고릅니다.
3. 에이전트가 결정을 TASK_SPEC에 기록하고 추가하거나 바꾼 부분을 보여 줍니다.
4. 파일에서 해당 부분을 읽고 의미가 보존되었는지, 불필요한 조건이 들어가지는 않았는지, 기존 기록과 모순되지 않는지 확인합니다. 문제가 있으면 수정해 달라고 요청하고 다시 확인합니다.

결정 하나를 내릴 때마다 영향을 받은 줄과 관련 조건을 확인하면 충분합니다. 구현을 시작하기 전에는 파일 전체를 다시 읽으세요. 각 항목은 따로 보면 맞아도 함께 두면 서로 양립할 수 없는 요구가 될 수 있습니다. "명세를 업데이트했습니다"라는 메시지만으로는 문서에 무엇이 들어갔는지 알 수 없습니다.

CLAUDE.md와는 목적이 다릅니다. "프로젝트의 모든 UI 문구는 한국어로 작성합니다"는 프로젝트 전체에 적용되는 규칙입니다. "이번 작업에서는 팁 계산을 추가합니다"는 특정 작업의 조건입니다. 첫 번째는 CLAUDE.md에, 두 번째는 TASK_SPEC에 적는 것이 알맞습니다.

문서의 길이는 작업에 따라 달라집니다. 완성된 페이지에서 오타 하나를 고치는 일이라면 다음 정도면 충분합니다.

계산서 나누기 페이지에서 버튼 문구를 고쳐 주세요.
"게산하기" → "계산하기". 다른 부분은 바꾸지 마세요.
새 문구가 표시되고 버튼이 계속 계산하는지 확인하세요.

이처럼 짧은 TASK_SPEC을 tiny spec이라고 부르기도 합니다. 여기서는 논의할 내용이 거의 없습니다. 반면 새 계산기는 동작 방식이 여러 가지일 수 있어 두 줄만으로는 부족합니다. 결과에 영향을 주는 결정을 기록하는 것이 유용합니다. 제목이 많다고 해서 그 자체로 충분한 것은 아닙니다.

결과부터 정하기

아직 프로젝트가 없다고 가정해 보겠습니다. 친구 일행이 브라우저로 페이지를 열고 계산서 금액을 입력해 각자 낼 돈을 확인하려고 합니다. 에이전트에게 초안을 만들어 달라고 하겠습니다.

계산서 나누기 페이지를 위한 TASK_SPEC.md를 작성해 주세요.
아직 프로젝트는 없습니다. 계산서 금액과 인원수를 입력하고,
"계산하기"를 누르면 각자 낼 금액을 확인합니다.
설치 없이 브라우저에서 열리는 index.html이 결과물입니다.
합의한 조건을 기록하고, 미정인 내용은 질문으로 표시하세요.
작성한 내용을 보여 주세요. 페이지 코드는 아직 작성하지 마세요.

파일의 첫 부분은 예를 들면 다음과 같습니다.

## CONTEXT
식당에서 계산서를 빠르게 나누려는 일행입니다.
아직 프로젝트가 없고 작업 폴더는 비어 있습니다.

## DESIRED BEHAVIOR
사용자가 계산서 금액과 인원수를 입력합니다.
"계산하기"를 누르면 각자 낼 금액을 확인합니다.
결과물은 설치 없이 브라우저에서 열 수 있는
index.html 페이지입니다.

편집기에서 TASK_SPEC.md를 열고 요청과 기록을 대조해 보세요. 두 입력 항목과 동작, 각 참여자의 결과가 모두 있어야 합니다. 에이전트가 이름 입력이나 필수 회원 가입을 추가했다면 합의하지 않은 조건입니다. 파일에서 빼 달라고 요청하고 수정 내용을 확인하세요.

이제 누가 페이지를 사용하고 무엇을 얻는지 분명해졌습니다. 이 과정에서 산출물, 즉 에이전트가 작업해 내놓을 구체적인 결과도 정했습니다. 여기서는 페이지 파일입니다. 다른 작업이라면 버그 분석이나 코드 없는 변경 계획일 수도 있습니다. 원하는 결과를 분명하게 말하는 편이 좋습니다.

아직 JavaScript 함수나 참여자 정보를 저장할 방법을 정하지 않았습니다. 그런 결정은 구현에 속합니다. 작업 명세에서는 사용자가 보게 될 입력, 동작, 결과를 정하는 일이 더 중요합니다.

작업의 범위 정하기

이제 첫 번째 버전의 범위를 정하겠습니다. 에이전트에게 합의한 경계를 기록하고 업데이트한 부분을 보여 달라고 요청합니다.

## SCOPE
한 페이지에서 금액과 인원수를 입력하고,
총액을 똑같이 나누어 각자의 금액을 표시합니다.

## NON-GOALS
계정, 계산서 기록은 없습니다. 데이터를 저장할 필요가 없습니다.
음식별로 나누지 않습니다. 첫 버전에서는 똑같이 나눕니다.
구현 제약: 스타일과 스크립트를 포함한 HTML 파일 하나,
서버와 외부 라이브러리는 사용하지 않습니다.
페이지는 더블클릭으로 열려야 합니다.

이 부분에서는 제외 항목만 확인하는 것이 아닙니다. 균등 분배는 작업 범위 안에, 음식별 분배는 범위 밖에 있어야 합니다. 에이전트가 이를 혼동했다면 페이지 작업을 시작하기 전에 문서를 고치세요.

Scope는 작업 범위를 설명합니다. 여기서처럼 화면과 사용 시나리오로 정할 수도 있습니다. 정확한 경로를 알고 있으면 도움이 되지만, 파일 목록부터 시작할 필요는 없습니다. 기존 프로젝트를 수정하는데 필요한 페이지가 어디 있는지 모른다면 Claude Code에 먼저 변경 없이 찾아보고, 왜 그 파일을 골랐는지 설명해 달라고 하세요. 그런 다음 경로를 작업 명세에 추가하면 됩니다. 모르는 것은 괜찮지만, 지어내면 안 됩니다.

Non-goals는 의도적으로 제외한 항목입니다. "계산서 기록은 만들지 않습니다"라고 적으면 "불필요한 기능은 넣지 마세요"보다 경계가 분명합니다. 이유를 짧게 덧붙이면 여러분에게도 도움이 됩니다. 일주일 뒤에도 데이터 저장을 검토한 뒤 제외했다는 점을 알 수 있습니다.

구현 제약은 다른 질문에 답합니다. 어떤 접근 방식이 적합한가요? 계정은 불필요한 기능이고 서버는 여기서 제외한 구현 방식입니다. 짧은 문서에서는 제약이라는 점을 분명히 표시해 한 블록에 함께 적어도 됩니다.

범위 안에서 원하는 결과를 만들 수 있어야 합니다. 나중에 여러 기기에서 공유하는 계정과 기록이 필요해지면 "로컬 HTML 파일 하나"라는 조건을 다시 검토해야 합니다. 새 기능을 요구하면서 그 기능을 불가능하게 만드는 제한을 그대로 둘 수는 없습니다.

빠뜨린 0.01

지금까지는 꽤 명확해 보입니다. 코드를 작성하기 전에 작업 명세를 확인해 보겠습니다. 세 사람이 1000을 결제하면 각자 얼마를 표시해야 할까요?

333.33 + 333.33 + 333.33 = 999.99

0.01이 부족합니다. 첫 번째 사람이나 마지막 사람에게 더하거나, 사용자가 선택하게 할 수 있습니다. "똑같이 나눕니다"라는 말만으로는 정해지지 않습니다. 이건 JavaScript 지식이 아니라 여러분이 결정할 문제입니다.

이 페이지에서는 다음 규칙을 정하겠습니다. 각자 내는 금액의 차이는 0.01을 넘지 않습니다. 남은 금액은 목록의 앞사람부터 0.01씩 나눠 받습니다. 따라서 1000을 세 명이 나누면 333.34; 333.33; 333.33이 됩니다. 1000.01을 나누면 남는 금액이 0.02이므로 333.34; 333.34; 333.33입니다. 모든 금액이 배분되고 각자의 금액을 더하면 계산서 금액과 같습니다.

이제 에이전트에게 선택한 결정을 문서에 반영해 달라고 요청합니다.

반올림 규칙을 TASK_SPEC.md의 원하는 동작에 기록해 주세요.
변경한 줄을 보여 주세요. 코드는 아직 수정하지 마세요.

파일에 다음과 같은 내용이 추가되었는지 확인합니다.

각자 내는 금액의 합은 총액과 정확히 같습니다.
각자의 금액 차이는 0.01을 넘지 않습니다.
남은 금액은 목록의 앞사람부터 한 명당 0.01씩 받습니다.
페이지에는 이 규칙에 대한 설명이 있습니다.

"목록의 앞사람부터 한 명당 0.01씩"이라는 표현을 특히 주의해서 읽으세요. 에이전트가 "남은 금액 전부를 첫 번째 사람에게"라고 적었다면 결정이 달라진 것입니다. 0.02가 남으면 첫 번째 사람이 다른 사람보다 0.02를 더 내게 됩니다. 해당 줄을 고쳐 달라고 요청한 뒤 파일을 다시 확인하세요. 문구를 글자 그대로 맞출 필요는 없고 의미가 중요합니다.

작업 명세에 실제 숫자를 넣어 보는 이유가 여기에 있습니다. 에이전트가 임의로 방식을 선택해 코드를 작성하기 전에 빠진 결정을 찾았습니다. 지금까지 고친 것은 몇 줄뿐입니다.

Claude에게 질문을 맡기기

모든 빈틈을 혼자 발견하기는 어렵습니다. 초안을 에이전트에게 전달하고 작업 명세를 구체화하는 데 도움을 달라고 요청하세요.

@TASK_SPEC.md를 읽고 빠진 조건을 찾도록 도와주세요.
질문은 하나씩 하고, 각각에 대한 답안도 제안해 주세요.
제가 답하기 전까지는 제안을 합의된 것으로 간주하지 마세요.
결정을 하나씩 합의할 때마다 TASK_SPEC.md를 업데이트하고
제가 확인할 수 있도록 바뀐 부분을 보여 주세요.
코드는 아직 작성하지 마세요.

아래는 대화의 한 예입니다. 여러분의 세션에서는 다른 질문이 나올 수 있습니다. 여기서는 답변에 따라 문서가 어떻게 바뀌는지 살펴보세요.

Claude: "팁은 계산서 금액에 포함되어 있나요, 아니면 별도로 추가하나요? 기본값이 0인 별도 비율 입력란을 제안합니다."
여러분: "별도입니다. 계산서 금액을 기준으로 비율을 계산하고 팁을 더한 다음 전부 함께 나눕니다. 페이지에 팁 금액과 총액을 표시해 주세요."

Claude: "팁 금액에 0.01보다 작은 단위가 생기면 어떻게 반올림할까요? 소수점 둘째 자리로 반올림하고 정확히 0.005면 올리는 방법을 제안합니다."
여러분: "좋습니다. 먼저 팁 금액을 반올림한 다음 계산서에 더합니다. 그 뒤 우리 규칙에 따라 총액을 나눕니다."

Claude: "어떤 값을 입력할 수 있게 할까요? 양수 금액은 점이나 쉼표를 허용하고, 인원수는 1 이상의 정수, 팁 비율은 음수가 아닌 정수로 하면 어떨까요? 잘못된 값이면 입력란 옆에 안내를 표시합니다."
여러분: "좋습니다. 금액은 구분자 뒤에 소수점 두 자리까지 허용하고 천 단위 구분은 사용하지 않습니다. 입력란이 비어 있거나 값이 잘못되면 이전에 계산했더라도 결과를 숨깁니다."

팁 외에도 입력 가능한 값과 반올림 순서, 오류가 있을 때의 동작을 정했습니다. 답변이 기록된 뒤 업데이트된 부분을 확인합니다.

팁: 별도 입력란에 0 이상의 정수를 입력하며 기본값은 0입니다.
팁 금액은 계산서 금액을 기준으로 계산하고 소수점 둘째 자리로
반올림합니다. 정확히 0.005면 올립니다.
반올림한 팁을 계산서에 더한 뒤 총액을 나눕니다.
팁 금액과 총액, 각자의 금액을 표시합니다.
값이 비어 있거나 유효하지 않으면 결과를 숨기고,
해당 입력란 옆에 안내를 표시합니다.

순서를 확인합니다. 먼저 팁을 반올림한 뒤 계산서에 더하고, 그다음 총액을 나눕니다. 같은 표현도 순서가 달라지면 요구사항이 달라집니다. 에이전트에게 scope도 업데이트해 달라고 요청하세요. 첫 버전에 팁 입력란과 총액 계산이 추가되었습니다. 에이전트가 채팅에서 반영했다고 답한 것으로 끝내지 말고, 두 블록이 실제로 모두 바뀌었는지 파일에서 살펴봅니다.

결과와 검증 방법

"각자 내는 금액의 합은 총액과 같습니다"는 결과에 대한 요구사항입니다. "1000, 인원수 3명, 팁 0%를 입력하고 버튼을 눌러 333.34, 333.33, 333.33이 표시되는지 확인합니다"는 검증 방법입니다. 수행할 동작과 예상 결과를 정합니다.

구현 전에 에이전트에게 이런 검증 사례를 몇 가지 파일에 추가해 달라고 요청하세요. 예상 숫자는 직접 확인합니다. 그렇지 않으면 결과를 그대로 받아들이고, 완성된 페이지에 맞춰 기대치를 슬며시 바꾸기 쉽습니다.

10.05인 행은 연산 순서를 확인합니다. 10%는 1.005이고 반올림하면 1.01입니다. 다른 단계에서 반올림하면 총액이 달라질 수 있습니다. 형식도 확인할 수 있도록 같은 값을 쉼표로 입력해 보세요. 10,05도 같은 결과가 나와야 합니다. 음수 금액, 소수 인원수, 음수 또는 소수 비율, 빈 팁 입력란도 각각 시험해 보세요. 이 경우에는 계산되면 안 됩니다.

중요한 조건마다 확인할 수 있는 결과가 있어야 합니다. "페이지가 열렸습니다"만으로 금액이 올바르다고 증명되지는 않습니다. 링크 주소가 맞다고 해서 원하는 페이지가 실제로 로드된다고 장담할 수 없는 것과 같습니다. 작업의 목적이었던 동작을 확인하세요.

TASK_SPEC 정리하기

논의가 진행되는 동안 에이전트는 결정 사항을 파일에 모았습니다. 이제 답변이 반영되었는지, 검증 방법이 요구사항과 맞는지, 오래된 조건이 남아 있지는 않은지 전체를 다시 읽어 보겠습니다. 아래는 예제의 최종 문서입니다. 여섯 가지 핵심 항목은 context, desired behavior, scope, non-goals, verification plan, safe start입니다. 제목 덕분에 필요한 부분을 빠르게 찾을 수 있고, 내용은 작업을 검토하며 정리했습니다.

# TASK_SPEC.md

## CONTEXT
식당 계산서를 나누려는 일행입니다.
새 프로젝트는 아직 없고 작업 폴더에는 TASK_SPEC.md만 있습니다.

## DESIRED BEHAVIOR
결과물은 더블클릭으로 열리는 index.html과
검증 방법에 대한 짧은 설명입니다.
페이지에는 입력란 세 개와 "계산하기" 버튼이 있습니다.
- 계산서 금액은 0보다 크고 소수점 이하 두 자리까지 허용합니다.
  구분자는 점 또는 쉼표이며 천 단위 구분자는 사용하지 않습니다.
- 인원수는 1 이상의 정수입니다.
- 팁 비율은 0 이상의 정수이며 기본값은 0입니다.
팁은 계산서 금액을 기준으로 계산하고 소수점 둘째 자리로
반올림합니다. 정확히 0.005면 올립니다.
반올림한 팁을 계산서에 더한 뒤 총액을 나눕니다.
팁과 총액, 번호가 붙은 각 참여자의 금액을 표시합니다.
각자 내는 금액의 합은 총액과 같고 차이는 0.01 이하입니다.
남은 금액은 목록의 앞사람부터 0.01씩 배분합니다.
페이지에는 이 규칙에 대한 설명이 있습니다.
값이 비어 있거나 유효하지 않으면 결과를 숨기고,
잘못 입력한 칸 옆에 안내를 표시합니다.

## SCOPE
한 페이지에 입력란 세 개와 계산, 안내, 금액 표시를 제공합니다.
설명한 규칙에 따라 총액을 똑같이 나누고 남은 금액을 배분합니다.

## NON-GOALS
계정과 계산서 기록은 필요하지 않습니다. 데이터를 저장하지 않습니다.
음식별로 나누지 않습니다. 다른 버전의 계산기 기능입니다.
제약: 스타일과 스크립트는 index.html 안에 둡니다.
파일을 로컬에서 열 수 있도록 서버와 외부 라이브러리는 쓰지 않습니다.

## VERIFICATION PLAN
index.html을 더블클릭해 엽니다. "계산하기"를 누릅니다.
- 1000 / 3명 / 0% → 333.34; 333.33; 333.33;
- 1000.01 / 3명 / 0% → 333.34; 333.34; 333.33;
- 1000 / 3명 / 10% → 팁 100.00, 총액 1100.00,
  각자 366.67; 366.67; 366.66;
- 10.05 / 3명 / 10% → 팁 1.01, 총액 11.06,
  각자 3.69; 3.69; 3.68; 10,05를 입력해도 같은 결과입니다.
- 1000 / 1명 / 0% → 한 사람의 몫은 1000.00입니다.
각 경우에 금액을 모두 더해 총액과 비교합니다.
인원수에 0과 소수를 입력하고, 금액에 음수를 입력합니다.
음수 또는 소수 비율, 소수점 이하 두 자리를 넘는 금액,
각 입력란을 차례로 비우는 경우도 확인합니다.
잘못 입력한 칸 옆에 안내가 표시되고, 계산 후에도 결과가 숨겨져야 합니다.
금액 번호와 남은 금액 배분 규칙 설명을 확인합니다.

## SAFE START
작업 명세를 읽고 작업 폴더의 내용을 확인합니다.
프로젝트 파일이 이미 있으면 멈추고 작업 내용을 다시 묻습니다.
기존 파일은 덮어쓰거나 삭제하지 않습니다.
먼저 코드 없이 질문과 계획을 제시하고 승인을 기다립니다.
구현에 scope 밖의 변경이 필요하면
변경 전에 작업 명세부터 구체화합니다.

문서에는 실제로 필요했던 결정만 추가되었습니다. JavaScript를 작성하는 단계별 지침은 없지만 팁을 어떻게 계산하고 금액을 어떻게 확인할지 나와 있습니다. 여러분의 작업에는 이보다 적은 정보만 필요할 수도 있습니다.

여러분의 작업 명세를 작성할 때 다음 간단한 참고 목록을 확인하면 편리합니다.

조건이 바뀌면

간단한 확인 문제입니다. 사용자가 작업 명세를 읽고 말합니다. "비율은 불편해요. 예를 들어 100처럼 팁 금액을 직접 입력하고 싶어요." TASK_SPEC의 어느 부분을 업데이트해야 할까요? 설명을 읽기 전에 먼저 생각해 보세요.

원하는 동작에서는 비율 입력란을 팁 금액으로 바꿉니다. 0 이상의 값으로 점이나 쉼표를 사용할 수 있고 소수점 이하는 두 자리까지 허용합니다. 기본값은 0으로 유지합니다. 비율 계산식과 계산된 팁의 반올림을 없애고 입력한 금액을 계산서에 더합니다. scope에서는 계산 방식이 바뀌고 verification plan에서는 입력값과 잘못된 입력 사례를 바꿉니다. 총액을 나누는 규칙과 non-goals는 그대로입니다.

"계산서 1000, 팁 100, 참여자 3명"을 확인하면 익숙한 366.67; 366.67; 366.66이 나옵니다. 하지만 이 숫자만으로는 고정 금액 팁을 쓰는 새 버전과 10% 팁을 쓰는 이전 버전을 구분할 수 없습니다. 다른 계산서를 추가해 보세요. 500에 고정 금액 100을 더하고 두 명이 나눕니다. 각자 300이어야 합니다. 이전의 10% 방식이라면 각자 275를 냈을 것입니다. 이 검증으로 규칙이 바뀌었는지 확인할 수 있습니다.

에이전트에게 원하는 동작과 scope, 검증 방법을 업데이트한 뒤 변경한 부분을 모두 보여 달라고 요청하세요. 파일을 열어 이전 비율 계산식이 삭제되었는지, 새 검증 사례가 금액 입력에 맞는지 확인합니다. 이전 계산식과 "이제 금액으로 입력"이라는 새 메모를 함께 남기지 마세요. 작업 명세는 하나의 일관된 답을 제시해야 합니다. 앞의 주요 예제에서는 원래의 비율 방식을 유지했고, 여기서는 그 방식을 바꾸는 별도 사례를 살펴봤습니다.

Claude Code와 함께 작업하기

개별 변경 사항을 확인한 뒤 구현을 시작하기 전에 TASK_SPEC 전체를 다시 읽으세요. 목표와 범위, 검증 방법이 모두 같은 작업을 설명하는지 확인합니다. 그런 다음 에이전트에게 파일을 명시적으로 전달하세요.

@TASK_SPEC.md를 읽어 주세요. 먼저 모순이 있는지,
추가로 확인해야 할 조건이 남아 있는지 살펴보세요.
간단한 계획과 만들거나 수정할 파일 목록을 보여 주세요.
계획을 승인하기 전까지 코드를 변경하지 마세요.

이제 구현 전에 확인할 계획이 있습니다. 계산서 저장을 위한 서버가 계획에 포함되어 있다면 수정을 요청하세요. 기록 기능은 제외했고 페이지는 로컬에서 열려야 합니다. 계획이 적절하면 구현을 승인합니다. 그런 다음 결과 파일을 열고, 계산에 성공한 뒤 잘못된 값을 입력하는 경우까지 기록된 시나리오를 확인하세요.

Non-goals는 문서에 적힌 조건일 뿐, 기술적으로 변경을 차단하지는 않습니다. 따라서 계획 검토와 결과 확인이 모두 중요합니다. 에이전트의 "완료했습니다"라는 메시지는 무엇을 했는지 파악하는 데 도움이 되지만, 여러분이 직접 확인할 기준 숫자를 대신하지는 않습니다.

작업이 끝난 뒤에도 프로젝트에 TASK_SPEC을 보관한다면 작업을 종료 상태로 표시하세요. 작업 중에는 파일의 결정 사항을 최신 상태로 유지합니다. 문구 작성과 기록은 에이전트에게 맡기고, 결정은 문서 자체에서 확인하세요. 논의 후에는 변경된 부분을, 구현 전에는 파일 전체를 읽습니다.