jutell 1.0.1 → 2.0.0

package/assets/skill/references/report-format.md

@@ -1,203 +1,209 @@
-# JuTell — Report Format Reference
-
-이 문서는 `docs/BEGINNER_REPORT_SPEC.md`의 짧은 실행용 형식이다. 상황에 맞는 형식만 사용하고 내용을 반복하지 않는다.
-
-## 1. 정보 체계
-
-서로 다른 네 가지 정보를 섞지 않는다.
-
-* 근거 출처: 파일, Git, 명령, 브라우저 또는 실제 실행, 코드 예상, 사용자 제공 정보
-* 확인 상태: 확인됨, 일부 확인, 확인하지 못함
-* 사용자 행동: 사용자 확인 필요, 추가 테스트 권장, 설정 필요, 사용자 결정 필요
-* 보고서 상태: 확인 완료, 추가 확인 필요, 일부 확인, 작업 보류, 범위 밖
-
-검증 결과는 별도로 표시한다.
-
-* 통과
-* 일부 통과
-* 실패
-* 실행하지 못함
-* 실행하지 않음
-* 검증 수단 없음
-
-중요한 주장에는 가능한 경우 근거와 확인 상태를 함께 적는다. 코드만 보고 예상한 내용은 `근거: 코드 예상`과 `확인 상태: 확인하지 못함`으로 표시한다.
-
-## 2. 단순 작업 보고
-
-문구, 색상, 작은 화면 배치처럼 위험이 낮은 작업에 사용한다.
-
-```md
-## 변경 요약
-<무엇을 바꿨는지 한두 문장>
-
-## 사용자에게 달라지는 점
-<확인됨 또는 예상됨을 표시한 화면 변화>
-
-## 프로그램 내부에서 달라진 점
-<내부 기능 변화 또는 없음>
-
-## 주요 수정 파일
-- `<파일>` — <역할 한 문장>
-
-## 검증 결과
-- 근거: <출처>
-- 확인 상태: <상태>
-- <실행한 검증과 실행하지 않은 검증>
-
-## 위험과 사용자 확인
-- 위험도: <낮음/중간/높음/판정 불가>
-- 근거: <짧은 이유>
-- <필요한 사용자 행동>
-- 보고서 상태: <상태>
-```
-
-단순 작업은 기본 항목마다 1~2문장, 주요 파일 최대 3개, 전체 기본 12문장 또는 약 25줄을 우선한다. 안전 문제나 중요한 실패가 있으면 정확한 경고를 우선한다.
-
-## 3. 일반 작업 보고
-
-기능 동작이 바뀌거나 여러 파일이 수정된 경우 사용한다.
-
-* 기본 6개 항목을 유지한다.
-* 주요 파일은 최대 5개를 설명한다.
-* 검증 결과, 미확인 항목, 위험도 근거를 분리한다.
-* 나머지 파일은 필요할 때 목록이나 개수로 요약한다.
-
-## 4. 최소 보고
-
-사용자가 상세 보고를 생략해달라고 요청한 경우 사용한다.
-
-```md
-작업 완료 여부: <완료/미완료>
-주요 수정 파일: <파일 또는 확인하지 못함>
-중요한 실패 또는 확인하지 못한 항목: <내용 또는 없음>
-```
-
-안전 문제, 데이터 손실 가능성, 비밀정보 노출, 핵심 검증 실패는 최소 보고에서도 생략하지 않는다.
-
-## 5. 계획 요청
-
-실제 변경 전에는 완료 보고서처럼 쓰지 않는다.
-
-* 변경 목표
-* 예상 변경 범위
-* 영향을 받을 수 있는 기능
-* 확인할 파일
-* 필요한 검증
-* 아직 결정되지 않은 사항
-
-## 6. 코드 또는 파일 설명 요청
-
-전체 작업 보고서를 강제로 만들지 않는다. 요청한 범위에서 필요한 항목만 설명한다.
-
-* 이 코드나 파일의 역할
-* 언제 사용되는지
-* 입력과 결과 중 필요한 내용
-* 수정 시 영향 가능성
-
-여러 코드 블록을 한 줄씩 설명하지 않고 기능 블록으로 묶는다.
-
-## 6.5 코드 또는 Diff 설명
-
-코드·Diff 원문을 요청받았거나 실제로 제시한 경우에만 적용한다. 코드 원문을 제시하지 않은 일반 완료 보고에는 강제하지 않는다.
-
-* 모든 줄을 하나씩 해설하지 않는다.
-* 기능 단위로 묶어 설명한다.
-* 파일 역할
-* 변경 전 문제
-* 변경한 내용
-* 사용자에게 보이는 변화
-* 수정 시 주의할 영향
-* 확인된 사실과 예상 구분
-* Diff가 매우 길면 핵심 구간만 설명하고 전체 원문 반복 금지
-
-```md
-### 변경 내용 설명
-
-- 이 코드는 <파일 역할>.
-- 기존에는 <변경 전 문제>.
-- 이제 <변경한 내용>과 <사용자에게 보이는 변화>.
-- 주의: <수정 시 영향 또는 확인 상태>.
-```
-
-## 6.6 다음 행동 제안
-
-`nextActionSuggestions`가 활성일 때 보고서 마지막에 한 문장 제안을 **최대 3개**만 추가한다. 다음 경우에만 추가한다.
-
-* 사용자가 직접 확인해야 할 항목이 남은 경우
-* 검증되지 않아 보류된 항목이 있는 경우
-* 설정이 필요한 경우
-* 데이터 손실·보안 위험이 확인된 경우
-
-```md
-## 다음 행동 제안
-- 실제 화면에서 검색 버튼을 눌러 확인해주세요.
-- `WEATHER_API_KEY` 설정을 마치면 결과를 다시 확인해주세요.
-```
-
-제안은 보고서에 이미 있는 확인 항목 중에서만 고르고, 추측이나 새 작업을 제안하지 않는다. 해당하지 않으면 섹션을 만들지 않는다.
-
-## 6.7 설명형 변경 요약
-
-`explainedDiff` Feature가 활성일 때 의미 있는 변경(기능 동작·화면 변화·데이터 처리 변화)은 무엇을 바꿨나요·왜 바꿨나요·어디를 바꿨나요·실제 중요한 변경 순으로 묶어 설명할 수 있다.
-
-* 근거가 없는 변경 이유는 추측하지 않고 "변경 이유는 Agent 결과에서 확인되지 않았습니다."로 표시한다.
-* 문구·색상·경로처럼 직접 다듬을 수 있는 위치의 코드 근거가 있을 때만 "내가 직접 다듬고 싶다면?"을 덧붙인다.
-* 중요한 코드 블록이 이미 작업 과정에서 확인되었고 사용자 이해에 실제 도움이 될 때만 1~2개까지 `[중요한 코드]` / `[쉽게 보면]` / `[영향]` 형식으로 보여준다. 이 섹션만을 위해 파일을 다시 읽거나 git diff를 다시 실행하지 않는다.
-* `explainedDiff`가 OFF이면 Readable Code도 생략한다. 사용자가 코드 설명을 명시한 경우만 예외다.
-* 단순 작업에는 이 형식을 강제하지 않고 기존 6개 항목을 유지한다.
-
-형식과 예시는 `references/explained-diff-format.md`를 따른다.
-
-## 6.8 다음 AI에게 전달하기
-
-`requestBuilder`가 활성이고 사용자가 다음 AI에게 넘기기·세션 마무리·이어서 할 일 정리를 요청하면, 현재 작업에서 이미 아는 근거만으로 아래 형식을 만든다.
-
-* 지금 하던 일
-* 방금 끝난 것
-* 확인된 것
-* 아직 확인하지 못한 것
-* 다음에 해줬으면 하는 것
-* 먼저 보면 좋은 파일
-* (해당할 때만) 건드리면 안 되는 것 / 사용자 결정이 필요한 것
-
-Request Builder의 `NEXT_AGENT_HANDOFF` 템플릿 또는 세션 `SESSION_SUMMARY`를 재사용해도 된다. 저장소 재탐색, 테스트 재실행, 자동 전송, HTML/클라우드 산출물은 만들지 않는다.
-
-## 6.9 말투 프리셋 (`voice.preset`)
-
-`.jutell.json`의 `voice.preset`이 있으면 보고 문체에만 적용한다. MCP `voiceRule`이 보이면 그것을 우선한다.
-
-* `default` — 일반적이고 명확한 비개발자용 설명
-* `plain` — 짧고 직접적인 평이한 문장
-* `learning` — 필요한 용어를 조금 더 풀어 설명
-* `jutell` — 친절하고 자연스럽고 간결한 JuTell Style
-
-말투를 바꿔도 사실·검증·위험·사용자 행동은 줄이거나 과장하지 않는다. 스타일 학습·임베딩·자동 말투 추론은 하지 않는다.
-
-## 7. 금지 표현
-
-근거가 없으면 다음 표현을 사용하지 않는다.
-
-* 완벽하게 작동합니다
-* 모든 문제가 해결됐습니다
-* 오류가 전혀 없습니다
-* 기존 기능에 영향이 없습니다
-* 배포해도 됩니다
-* 안전합니다
-* 모든 테스트가 통과했습니다
-* 화면이 정상적으로 표시됩니다
-
-대신 확인한 범위, 실행한 검증, 남은 미확인 사항을 적는다.
-
-## 8. 로컬 Feature 설정
-
-프로젝트 루트의 `.jutell.json` 우선, 없으면 `.beginner-bridge.json`을 확인한다.
-
-* 파일이 없으면 `balanced` 기본값을 사용한다.
-* JSON, Profile, Feature ID, 값 형식 또는 limits가 잘못되면 설정 전체를 추측하지 않고 `balanced`로 진행한다.
-* 잘못된 설정이 있었을 때만 설정 문제를 짧게 알리고 설정 파일 전체를 출력하지 않는다.
-* 명시적 `features`와 `limits`는 Profile 기본값보다 우선한다.
-* 사용자가 요청한 보고 형식과 안전상 강제 보고 항목은 Feature를 끄더라도 적용한다.
-* 실패, 핵심 검증 실패, 중요한 미확인 사항, 높은 위험·판정 불가, 비밀정보·데이터 손실 위험, 범위 밖 변경과 작업 보류 사유는 숨기지 않는다.
-* limits는 선택 정보의 길이와 수에 적용하며 안전상 강제 정보에는 적용하지 않는다.
-
-Feature ID별 상세 예외는 `references/feature-registry.md`, 전체 정책은 `docs/FEATURE_CONFIGURATION.md`를 참조한다.
+# JuTell — Report Format Reference
+
+이 문서는 `docs/BEGINNER_REPORT_SPEC.md`의 짧은 실행용 형식이다. 상황에 맞는 형식만 사용하고 내용을 반복하지 않는다.
+
+## 1. 정보 체계
+
+서로 다른 네 가지 정보를 섞지 않는다.
+
+* 근거 출처: 파일, Git, 명령, 브라우저 또는 실제 실행, 코드 예상, 사용자 제공 정보
+* 확인 상태: 확인됨, 일부 확인, 확인하지 못함
+* 사용자 행동: 사용자 확인 필요, 추가 테스트 권장, 설정 필요, 사용자 결정 필요
+* 보고서 상태: 확인 완료, 추가 확인 필요, 일부 확인, 작업 보류, 범위 밖
+
+이번 요청이 실제로 원하는 결과를 만들어냈는지, 사용자가 말한 건드리지 말 것·유지할 것·완료 조건이 실제로 유지됐는지 확인하지 못했다면 `확인 완료`를 쓰지 않는다. 관련 검증이 통과했다는 사실만으로 이 판단을 대신하지 않는다 — 검증은 실제로 다룬 범위만 증명한다. 완료에 필수적인 미확인·실패를 이미 알고 있다면 `위험과 사용자 확인`에 짧게 밝히고 `확인 완료`가 아닌 실제로 맞는 상태를 쓴다.
+
+검증 결과는 별도로 표시한다.
+
+* 통과
+* 일부 통과
+* 실패
+* 실행하지 못함
+* 실행하지 않음
+* 검증 수단 없음
+
+중요한 주장에는 가능한 경우 근거와 확인 상태를 함께 적는다. 코드만 보고 예상한 내용은 `근거: 코드 예상`과 `확인 상태: 확인하지 못함`으로 표시한다.
+
+이번 요청이 요구하지 않는 더 나은 개선을 발견해도 조용히 수행하지 않는다. 유용하면 수행하지 않고 다음 행동 제안(6.6)이나 범위 밖 관찰로 짧게만 언급하며, 건드리지 않았다는 사실 자체를 숨기지 않는다.
+
+## 2. 단순 작업 보고
+
+문구, 색상, 작은 화면 배치처럼 위험이 낮은 작업에 사용한다.
+
+```md
+## 변경 요약
+<무엇을 바꿨는지 한두 문장>
+
+## 사용자에게 달라지는 점
+<확인됨 또는 예상됨을 표시한 화면 변화>
+
+## 프로그램 내부에서 달라진 점
+<내부 기능 변화 또는 없음>
+
+## 주요 수정 파일
+- `<파일>` — <역할 한 문장>
+
+## 검증 결과
+- 근거: <출처>
+- 확인 상태: <상태>
+- <실행한 검증과 실행하지 않은 검증>
+
+## 위험과 사용자 확인
+- 위험도: <낮음/중간/높음/판정 불가>
+- 근거: <짧은 이유>
+- <필요한 사용자 행동>
+- 보고서 상태: <상태>
+```
+
+단순 작업은 기본 항목마다 1~2문장, 주요 파일 최대 3개, 전체 기본 12문장 또는 약 25줄을 우선한다. 안전 문제나 중요한 실패가 있으면 정확한 경고를 우선한다.
+
+완료에 필수적인 미확인·실패를 이미 알고 있으면, 형식을 위한 별도 항목을 만들지 않고 `위험과 사용자 확인`에 그 사실을 짧게 밝힌다(예: "외부 신원 인증 서비스 실제 연결은 확인하지 못했습니다"). 그런 사실이 있으면 `보고서 상태`에 `확인 완료`를 쓰지 않는다.
+
+## 3. 일반 작업 보고
+
+기능 동작이 바뀌거나 여러 파일이 수정된 경우 사용한다.
+
+* 기본 6개 항목을 유지한다.
+* 주요 파일은 최대 5개를 설명한다.
+* 검증 결과, 미확인 항목, 위험도 근거를 분리한다.
+* 나머지 파일은 필요할 때 목록이나 개수로 요약한다.
+
+## 4. 최소 보고
+
+사용자가 상세 보고를 생략해달라고 요청한 경우 사용한다.
+
+```md
+작업 완료 여부: <완료/미완료>
+주요 수정 파일: <파일 또는 확인하지 못함>
+중요한 실패 또는 확인하지 못한 항목: <내용 또는 없음>
+```
+
+안전 문제, 데이터 손실 가능성, 비밀정보 노출, 핵심 검증 실패는 최소 보고에서도 생략하지 않는다.
+
+## 5. 계획 요청
+
+실제 변경 전에는 완료 보고서처럼 쓰지 않는다.
+
+* 변경 목표
+* 예상 변경 범위
+* 영향을 받을 수 있는 기능
+* 확인할 파일
+* 필요한 검증
+* 아직 결정되지 않은 사항
+
+## 6. 코드 또는 파일 설명 요청
+
+전체 작업 보고서를 강제로 만들지 않는다. 요청한 범위에서 필요한 항목만 설명한다.
+
+* 이 코드나 파일의 역할
+* 언제 사용되는지
+* 입력과 결과 중 필요한 내용
+* 수정 시 영향 가능성
+
+여러 코드 블록을 한 줄씩 설명하지 않고 기능 블록으로 묶는다.
+
+## 6.5 코드 또는 Diff 설명
+
+코드·Diff 원문을 요청받았거나 실제로 제시한 경우에만 적용한다. 코드 원문을 제시하지 않은 일반 완료 보고에는 강제하지 않는다.
+
+* 모든 줄을 하나씩 해설하지 않는다.
+* 기능 단위로 묶어 설명한다.
+* 파일 역할
+* 변경 전 문제
+* 변경한 내용
+* 사용자에게 보이는 변화
+* 수정 시 주의할 영향
+* 확인된 사실과 예상 구분
+* Diff가 매우 길면 핵심 구간만 설명하고 전체 원문 반복 금지
+
+```md
+### 변경 내용 설명
+
+- 이 코드는 <파일 역할>.
+- 기존에는 <변경 전 문제>.
+- 이제 <변경한 내용>과 <사용자에게 보이는 변화>.
+- 주의: <수정 시 영향 또는 확인 상태>.
+```
+
+## 6.6 다음 행동 제안
+
+`nextActionSuggestions`가 활성일 때 보고서 마지막에 한 문장 제안을 **최대 3개**만 추가한다. 다음 경우에만 추가한다.
+
+* 사용자가 직접 확인해야 할 항목이 남은 경우
+* 검증되지 않아 보류된 항목이 있는 경우
+* 설정이 필요한 경우
+* 데이터 손실·보안 위험이 확인된 경우
+
+```md
+## 다음 행동 제안
+- 실제 화면에서 검색 버튼을 눌러 확인해주세요.
+- `WEATHER_API_KEY` 설정을 마치면 결과를 다시 확인해주세요.
+```
+
+제안은 보고서에 이미 있는 확인 항목 중에서만 고르고, 추측이나 새 작업을 제안하지 않는다. 해당하지 않으면 섹션을 만들지 않는다.
+
+## 6.7 설명형 변경 요약
+
+`explainedDiff` Feature가 활성일 때 의미 있는 변경(기능 동작·화면 변화·데이터 처리 변화)은 무엇을 바꿨나요·왜 바꿨나요·어디를 바꿨나요·실제 중요한 변경 순으로 묶어 설명할 수 있다.
+
+* 근거가 없는 변경 이유는 추측하지 않고 "변경 이유는 Agent 결과에서 확인되지 않았습니다."로 표시한다.
+* 문구·색상·경로처럼 직접 다듬을 수 있는 위치의 코드 근거가 있을 때만 "내가 직접 다듬고 싶다면?"을 덧붙인다.
+* 중요한 코드 블록이 이미 작업 과정에서 확인되었고 사용자 이해에 실제 도움이 될 때만 1~2개까지 `[중요한 코드]` / `[쉽게 보면]` / `[영향]` 형식으로 보여준다. 이 섹션만을 위해 파일을 다시 읽거나 git diff를 다시 실행하지 않는다.
+* `explainedDiff`가 OFF이면 Readable Code도 생략한다. 사용자가 코드 설명을 명시한 경우만 예외다.
+* 단순 작업에는 이 형식을 강제하지 않고 기존 6개 항목을 유지한다.
+
+형식과 예시는 `references/explained-diff-format.md`를 따른다.
+
+## 6.8 다음 AI에게 전달하기
+
+`requestBuilder`가 활성이고 사용자가 다음 AI에게 넘기기·세션 마무리·이어서 할 일 정리를 요청하면, 현재 작업에서 이미 아는 근거만으로 아래 형식을 만든다.
+
+* 지금 하던 일
+* 방금 끝난 것
+* 확인된 것
+* 아직 확인하지 못한 것
+* 다음에 해줬으면 하는 것
+* 먼저 보면 좋은 파일
+* (해당할 때만) 건드리면 안 되는 것 / 사용자 결정이 필요한 것
+
+Request Builder의 `NEXT_AGENT_HANDOFF` 템플릿 또는 세션 `SESSION_SUMMARY`를 재사용해도 된다. 저장소 재탐색, 테스트 재실행, 자동 전송, HTML/클라우드 산출물은 만들지 않는다.
+
+## 6.9 말투 프리셋 (`voice.preset`)
+
+`.jutell.json`의 `voice.preset`이 있으면 보고 문체에만 적용한다. MCP `voiceRule`이 보이면 그것을 우선한다.
+
+* `default` — 일반적이고 명확한 비개발자용 설명
+* `plain` — 짧고 직접적인 평이한 문장
+* `learning` — 필요한 용어를 조금 더 풀어 설명
+* `jutell` — 친절하고 자연스럽고 간결한 JuTell Style
+
+말투를 바꿔도 사실·검증·위험·사용자 행동은 줄이거나 과장하지 않는다. 스타일 학습·임베딩·자동 말투 추론은 하지 않는다.
+
+## 7. 금지 표현
+
+근거가 없으면 다음 표현을 사용하지 않는다.
+
+* 완벽하게 작동합니다
+* 모든 문제가 해결됐습니다
+* 오류가 전혀 없습니다
+* 기존 기능에 영향이 없습니다
+* 배포해도 됩니다
+* 안전합니다
+* 모든 테스트가 통과했습니다
+* 화면이 정상적으로 표시됩니다
+
+대신 확인한 범위, 실행한 검증, 남은 미확인 사항을 적는다.
+
+## 8. 로컬 Feature 설정
+
+프로젝트 루트의 `.jutell.json` 우선, 없으면 `.beginner-bridge.json`을 확인한다.
+
+* 파일이 없으면 `balanced` 기본값을 사용한다.
+* JSON, Profile, Feature ID, 값 형식 또는 limits가 잘못되면 설정 전체를 추측하지 않고 `balanced`로 진행한다.
+* 잘못된 설정이 있었을 때만 설정 문제를 짧게 알리고 설정 파일 전체를 출력하지 않는다.
+* 명시적 `features`와 `limits`는 Profile 기본값보다 우선한다.
+* 사용자가 요청한 보고 형식과 안전상 강제 보고 항목은 Feature를 끄더라도 적용한다.
+* 실패, 핵심 검증 실패, 중요한 미확인 사항, 높은 위험·판정 불가, 비밀정보·데이터 손실 위험, 범위 밖 변경과 작업 보류 사유는 숨기지 않는다.
+* limits는 선택 정보의 길이와 수에 적용하며 안전상 강제 정보에는 적용하지 않는다.
+
+Feature ID별 상세 예외는 `references/feature-registry.md`, 전체 정책은 `docs/FEATURE_CONFIGURATION.md`를 참조한다.

package/assets/skill/references/risk-level-guide.md

@@ -1,85 +1,85 @@
-# JuTell — Risk Level Guide
-
-이 문서는 `docs/BEGINNER_REPORT_SPEC.md`의 위험도 규칙을 짧게 적용하기 위한 reference다. 위험도는 정상 작동 여부가 아니라 변경이 기존 기능에 미칠 수 있는 영향의 크기다.
-
-## 1. 낮음
-
-프로그램 핵심 동작에 영향을 줄 가능성이 작은 변경이다.
-
-* 일반 문구
-* 색상, 여백, 단순 화면 배치
-* 문서나 주석
-* 테스트 설명
-
-예: 로그인 버튼의 문구와 `#2563EB` 색상만 변경하고 로그인 처리 코드는 건드리지 않은 경우.
-
-## 2. 중간
-
-특정 기능이나 한정된 사용자 흐름의 동작에 영향을 줄 수 있는 변경이다.
-
-* 버튼 동작
-* 입력 검증
-* 특정 페이지 이동
-* 특정 기능의 상태 처리
-* 특정 페이지의 데이터 표시
-* 파일 업로드
-* 로컬 저장 방식
-
-예: 검색 실행 전에 빈 검색어인지 확인하는 조건을 추가한 경우.
-
-## 3. 높음
-
-여러 기능, 중요한 데이터, 보안 또는 운영 환경에 영향을 줄 수 있는 변경이다.
-
-* 로그인과 인증
-* 권한
-* 결제
-* 데이터베이스 구조
-* 공통 상태 관리
-* 공통 API 처리
-* 외부 서비스 연결
-* 비밀정보 처리
-* 배포 설정
-* 여러 기능이 사용하는 공통 로직
-
-## 4. 판정 불가
-
-실행 환경이 없다는 이유만으로 판정 불가로 만들지 않는다. 코드나 변경 범위 자체를 충분히 읽지 못해 영향도를 판단할 근거가 없을 때 사용한다.
-
-예:
-
-* 변경 파일을 열 수 없음
-* 기존 변경과 이번 변경을 구분할 수 없고 영향 범위도 확인하지 못함
-* 프로젝트 구조가 불명확해 수정 대상의 역할을 파악할 수 없음
-
-코드를 읽었지만 테스트나 브라우저를 실행하지 못한 경우에는 가능한 범위에서 위험도를 판단하고, 검증 상태를 별도로 표시한다.
-
-## 5. 여러 조건이 겹칠 때
-
-여러 위험도 조건에 해당하면 가장 높은 위험도를 적용한다. 파일 이름이 아니라 실제 변경 내용을 기준으로 한다.
-
-단, 인증 파일 안의 주석만 수정한 것처럼 실제 변경 내용이 문서·주석 수준인 경우에는 변경 내용에 맞춰 낮음으로 판단할 수 있다.
-
-위험도에는 한두 문장의 근거를 함께 작성한다.
-
-## 6. 검증 가능성과 분리
-
-위험도와 검증 가능성은 서로 다른 판단이다.
-
-* 위험도: 변경이 얼마나 넓고 중요한 기능에 영향을 줄 수 있는가
-* 검증 가능성: 테스트, 브라우저, 권한, 도구로 실제 결과를 확인할 수 있는가
-
-예:
-
-* 브라우저를 실행하지 못했지만 로그인 처리 코드를 읽음 → 위험도 높음, 화면 검증은 확인하지 못함
-* 파일을 읽지 못해 변경 범위를 모름 → 위험도 판정 불가
-
-## 7. V0.1 시나리오
-
-### 시나리오 A
-
-로그인 버튼 문구와 색상만 변경하면 낮음이다. 로그인 처리, 인증, 세션, 공통 버튼 동작까지 변경하면 실제 변경 범위에 따라 중간 또는 높음이다.
-
-### 시나리오 B
-
-검색어가 비어 있을 때 검색 요청을 막는 입력 조건 변경은 중간이다. 공통 검색 로직, 검색 API, 데이터 저장 방식을 함께 변경하면 높음으로 올린다.
+# JuTell — Risk Level Guide
+
+이 문서는 `docs/BEGINNER_REPORT_SPEC.md`의 위험도 규칙을 짧게 적용하기 위한 reference다. 위험도는 정상 작동 여부가 아니라 변경이 기존 기능에 미칠 수 있는 영향의 크기다.
+
+## 1. 낮음
+
+프로그램 핵심 동작에 영향을 줄 가능성이 작은 변경이다.
+
+* 일반 문구
+* 색상, 여백, 단순 화면 배치
+* 문서나 주석
+* 테스트 설명
+
+예: 로그인 버튼의 문구와 `#2563EB` 색상만 변경하고 로그인 처리 코드는 건드리지 않은 경우.
+
+## 2. 중간
+
+특정 기능이나 한정된 사용자 흐름의 동작에 영향을 줄 수 있는 변경이다.
+
+* 버튼 동작
+* 입력 검증
+* 특정 페이지 이동
+* 특정 기능의 상태 처리
+* 특정 페이지의 데이터 표시
+* 파일 업로드
+* 로컬 저장 방식
+
+예: 검색 실행 전에 빈 검색어인지 확인하는 조건을 추가한 경우.
+
+## 3. 높음
+
+여러 기능, 중요한 데이터, 보안 또는 운영 환경에 영향을 줄 수 있는 변경이다.
+
+* 로그인과 인증
+* 권한
+* 결제
+* 데이터베이스 구조
+* 공통 상태 관리
+* 공통 API 처리
+* 외부 서비스 연결
+* 비밀정보 처리
+* 배포 설정
+* 여러 기능이 사용하는 공통 로직
+
+## 4. 판정 불가
+
+실행 환경이 없다는 이유만으로 판정 불가로 만들지 않는다. 코드나 변경 범위 자체를 충분히 읽지 못해 영향도를 판단할 근거가 없을 때 사용한다.
+
+예:
+
+* 변경 파일을 열 수 없음
+* 기존 변경과 이번 변경을 구분할 수 없고 영향 범위도 확인하지 못함
+* 프로젝트 구조가 불명확해 수정 대상의 역할을 파악할 수 없음
+
+코드를 읽었지만 테스트나 브라우저를 실행하지 못한 경우에는 가능한 범위에서 위험도를 판단하고, 검증 상태를 별도로 표시한다.
+
+## 5. 여러 조건이 겹칠 때
+
+여러 위험도 조건에 해당하면 가장 높은 위험도를 적용한다. 파일 이름이 아니라 실제 변경 내용을 기준으로 한다.
+
+단, 인증 파일 안의 주석만 수정한 것처럼 실제 변경 내용이 문서·주석 수준인 경우에는 변경 내용에 맞춰 낮음으로 판단할 수 있다.
+
+위험도에는 한두 문장의 근거를 함께 작성한다.
+
+## 6. 검증 가능성과 분리
+
+위험도와 검증 가능성은 서로 다른 판단이다.
+
+* 위험도: 변경이 얼마나 넓고 중요한 기능에 영향을 줄 수 있는가
+* 검증 가능성: 테스트, 브라우저, 권한, 도구로 실제 결과를 확인할 수 있는가
+
+예:
+
+* 브라우저를 실행하지 못했지만 로그인 처리 코드를 읽음 → 위험도 높음, 화면 검증은 확인하지 못함
+* 파일을 읽지 못해 변경 범위를 모름 → 위험도 판정 불가
+
+## 7. V0.1 시나리오
+
+### 시나리오 A
+
+로그인 버튼 문구와 색상만 변경하면 낮음이다. 로그인 처리, 인증, 세션, 공통 버튼 동작까지 변경하면 실제 변경 범위에 따라 중간 또는 높음이다.
+
+### 시나리오 B
+
+검색어가 비어 있을 때 검색 요청을 막는 입력 조건 변경은 중간이다. 공통 검색 로직, 검색 API, 데이터 저장 방식을 함께 변경하면 높음으로 올린다.