프로젝트 지침과 도구 범위

지침이 사라지면 수정 기준도 흔들립니다

할 일 앱의 조회 순서를 고친 다음 날 다른 세션에서 작업한다고 가정합니다. 새 담당자가 지난 대화만 찾으면 어떤 테스트를 보호해야 하는지, 운영 접근이 허용되는지 알기 어렵습니다. 교육 담당자는 기억력이 좋은 신입보다 같은 기준으로 일하는 신입을 원합니다. 이번에는 반복되는 규칙을 RULES.md에 남깁니다. 오늘의 수정 요청과 실행 결과를 함께 넣지 않고, 다음 작업에서도 유효한 경계만 적습니다. 파일을 만든 뒤 실제 변경 목록과 대조해야 지침이 업무 기준으로 작동합니다.

이 모듈의 준비와 출발점

브라우저 과제는 Python 표준 입력에서 JSON 하나를 읽으며 외부 패키지가 필요하지 않습니다. 로컬 과제는 Python 3·bash, 미션은 JDK 17·Spring Boot 3.1.5와 제공 Maven Wrapper를 사용합니다. 내려받은 starter와 solution을 별도 폴더에 풀고 각 README의 명령을 그 폴더에서 실행합니다. Maven 안내 명령은 ./mvnw test이며 의존성 캐시가 준비된 환경에서는 ./mvnw -o -q test로 확인합니다. AI 계정 없이 합성 fixture만으로 수행할 수 있습니다. 미션 starter는 앞 모듈 solution 전체를 이어받아 Java 앱이 아니라 새 하네스에 결함을 넣었습니다.

RULES.md는 이 프로젝트의 약속입니다

RULES.md라는 이름은 이 교육 프로젝트에서 정한 이름입니다. 파일 이름만으로 어떤 AI 도구가 자동으로 읽거나 강제한다고 가정하지 않습니다. 작업 요청에 먼저 RULES.md를 읽고 적용 경로와 검사 명령을 되짚어 달라고 적습니다. 규칙을 읽었다는 답변도 준수 증거는 아닙니다. 수정 후 파일 목록과 실행 기록을 확인합니다. 제품별 설정이나 지침 탐색 방식 대신, 도구와 관계없이 사람이 재확인할 수 있는 프로젝트 문서를 만드는 것이 이번 레슨의 목표입니다.

수정 경로를 과제 단위로 좁힙니다

이번 미션에서 편집할 파일은 harness.py·RULES.md·tasks.json·state.json·handoff.md입니다. 이전 Java 소스와 테스트, spec.md, Maven Wrapper는 그대로 유지합니다. harness.py를 고치려다 테스트 기대값을 바꾸면 범위를 벗어납니다. 지침에는 이 파일 목록과 보호 대상을 나란히 씁니다. 경로 뒤에 전체라는 말을 붙여 무관한 폴더까지 허용하지 않습니다. 다음 모듈에서 경계를 바꿀 때에는 새 과제 목적과 보호 파일을 검토한 뒤 문서와 검사 기준을 함께 갱신합니다.

명령은 실행 위치와 판정을 함께 적습니다

검증 절에는 프로젝트 루트에서 ./mvnw test를 실행한다고 적고, 기존 회귀와 HarnessTest가 성공해야 한다는 기준을 덧붙입니다. Python 참조 모델은 bash check_reference.sh, 새 하네스는 python3 -m unittest -v test_harness로 검사합니다. bash check.sh는 이를 묶고 보호 파일 검사와 재개 보고도 수행합니다. 실행 명령을 적을 때 서버 시작 명령과 단위 테스트 명령을 혼동하지 않습니다. 테스트가 실패하면 어느 검사에서 기대와 실제가 달랐는지 남기며 정상 종료 한 줄로 전체 요구 충족을 선언하지 않습니다.

문서상의 금지와 기술적 차단을 구별합니다

외부 동작 절에는 개인 제목·토큰·운영 설정의 외부 전송 금지, 운영 접속과 배포를 수행하지 않는다고 씁니다. 위험한 작업 금지라는 문장만으로는 메모 업로드가 허용되는지 판단하기 어렵습니다. 데이터 이름과 동작을 구체적으로 연결합니다. 이 문서는 접근 권한을 기술적으로 제한하지 않습니다. 파일을 읽고 명령을 실행하는 실제 도구의 통제는 다음 모듈에서 다룹니다. 이번에는 허용되지 않은 동작이 변경 내역이나 실행 기록에 있는지 직접 검토합니다.

지속 규칙과 오늘의 계획은 다릅니다

조회 순서 검사를 오늘 오후에 다시 실행한다는 요청은 tasks.json의 작업입니다. 생성 순서를 보존한다는 앱 계약은 spec.md에 두며 지침에서 그 문서를 참조합니다. 실행해 보니 한 검사가 실패했다는 관찰은 state.json과 로그로 남깁니다. 내일 먼저 볼 파일은 handoff.md에서 설명합니다. 모든 정보를 RULES.md에 합치면 시점이 다른 관찰이 지속 규칙처럼 보입니다. 이 레슨의 제출물에는 문서별 역할을 한 문장으로 적고 일회성 진행 보고가 지침에 섞이지 않았는지 확인합니다.

규칙 충돌은 확대 해석하지 않습니다

요청은 하네스만 수정하라고 했는데 제공된 AI 제안이 Java 테스트도 바꾸라고 할 수 있습니다. 제안은 검토 자료이므로 스스로 허용 경로를 넓히는 근거가 되지 않습니다. 변경을 적용하기 전에 하네스만으로 해결 가능한지 확인하고, 해결 불가능한 이유가 있으면 구체적인 파일과 요구를 남깁니다. 이번 과제는 보호 테스트를 바꾸지 않고 해결할 수 있습니다. 실패를 피하려고 지침을 완화하는 대신 원래 명세와 검사 결과를 읽는 습관을 익힙니다.

필수 절 검사도 한계가 있습니다

check_rules.py는 수정 경로·검증·외부 동작·기록이라는 제목과 몇 가지 문구가 있는지 검사합니다. RULES MISSING은 해당 문자열을 찾지 못했다는 뜻으로, 명령 실행 실패나 앱 결함이 아닙니다. 제목만 채우고 내용이 모호해도 기계 검사는 통과할 수 있습니다. 따라서 허용 파일을 실제로 식별할 수 있는지, 명령을 어디서 실행하는지, 외부 전송 금지 데이터가 분명한지 사람이 읽습니다. 자동 구조 검사와 의미 검토를 둘 다 제출 기준에 둡니다.

보호 파일 결과를 읽습니다

check_scope.py가 CHANGED와 경로를 출력하면 그 보호 파일의 바이트 해시가 제공 기준과 달라졌다는 뜻입니다. OUT_OF_SCOPE는 허용 목록에 없는 파일이 생겼다는 뜻입니다. 기능 오류와 별개로 원인을 조사합니다. 임시 실습 결과는 README가 정한 경로에만 남기고, 허용 목록 자체를 바꾸어 실패를 숨기지 않습니다. 작업자가 여러 명이면 본인 변경만 확인하고 다른 사람의 파일을 되돌리지 않습니다. 이 모듈의 로컬 ZIP은 각자 분리한 폴더에서 작업합니다.

신입에게 요청할 검토 문장

교육 담당자에게 제출할 때에는 이번 수정 대상은 harness.py이고 기존 Java 회귀는 보호하며 실패 근거는 evidence 로그에 남긴다고 설명합니다. AI를 사용했다면 지침 요약과 제안받은 부분, 본인이 실제 확인한 부분을 구별합니다. fixture만 사용했다면 사용한 합성 자료를 밝히면 됩니다. 긴 대화 전문을 지침에 붙일 필요는 없습니다. 다른 담당자가 문서를 읽고 같은 범위에서 시작할 수 있을 만큼 짧고 구체적인 문장을 남기는 것이 목적입니다.

설계 실습의 제출 기준

이번 레슨의 실습은 코드를 실행하는 채점 대신 RULES.md 초안을 작성하는 문서 과제입니다. 수정 경로·실행 위치·검사 명령·통과 기준·외부 금지 동작·기록 위치를 포함합니다. Java 테스트 변경, 개인 제목 업로드, 과거 통과 기록 복사를 제안한 세 상황에 대해 허용 여부와 근거 절을 덧붙입니다. 이어서 실제 미션의 RULES.md와 비교해 빠진 판단 기준을 보완합니다. 일반 지침 작성 방식과 도구별 차이는 더 읽기로 보내고 여기서는 할 일 앱의 경계를 완성합니다.