Branch Workflow

2026-09-15 개정(오너 지시, #1661·#1659) — 승격 검사 3단계 — ① 작업 PR→release는 큐 Merge Check만(PR 전 precheck 폐기) ② release→staging은 GitHub Full CI precheck 레인(static-checks + migration-smoke) ③ staging→main은 QA2 레인(qa2-product-contracts)만. QA1은 완전히 퇴역(어느 워크플로도 실행하지 않음). 아래 2026-09-10 배너와 본문의 precheck·full CI·재사용 서술은 그 개정 전 기록이다. 정본 = 릴리스 프로세스.

2026-09-10 승인 정책 (#1491, v0.17.8 대상): 작업 세션은 ci:precheck-local, 작업→release 큐는 Merge Check만 수행한다. 최종 release→staging 후보에서 full CI를 실행하고, staging→main은 동일 tree의 유효한 full 성공 기록과 현재 staging 배포·smoke 증거를 확인해 재사용한다. 명시적 merge:request --dry-run은 진단용 full 실행을 유지한다. 앱 main 6afe58ec에 설치됐으며 정상 큐의 실제 실행 시간과 운영 배포 성공은 아직 확인 전이다. 상세 상태는 적용 기록에서 구분한다. 아래 과거 전환 기록보다 이 절차가 우선한다.

#1463 저장소 분리 이후 적용: 아래 앱 release·DB·데이터 보호 규칙은 앱 저장소에 적용한다. 과거 docs/admin 결합 빌드·같은 SHA 배포·앱 main 문서 직행·문서 문자열 검사 설명은 이관 전 기록이다. 모든 문서와 작업 기록은 dekerd/Barbelic-docs에서 관리하며, 현행 저장소 경계와 문서·관리자 독립 운영이 그 부분을 대체한다. 세션 제목은 현재 Phase/전체 Phase 규칙을 따른다. 코드 준비·원격 활성화·실제 배포 성공은 독립 운영 문서의 기록으로 구분한다.

2026-09-09 개정 (이슈 #1456·#1457·#1458, 오너 결정) — 명령·워크플로 이름이 바뀌었다. 작업 PR 통합 요청 npm run merge:request(구 landing:request), PR 전 사전 검증 npm run ci:precheck-local(최신 release 합치기 → verify → 서버 변경 시 DB 단계, 브라우저 없음), 전체 검증 npm run ci:full-local(릴리스 큐 runner 안에서만; 세션은 --only <단계> 재현만). 워크플로 표시 이름: 3-Release Merge Request(release-merge-request.yml) · GitHub Full CI(policy-contract.yml) · 1-Production Deploy/2-Staging Deploy(production-deploy.yml·staging-deploy.yml, 단계 정의는 deploy-steps.yml) · Production smoke (manual) · Social login daily check · Daily data backup. landing:lock·db:preflight 스크립트는 폐기됐다(GitHub concurrency 가 잠금, DB 검사는 사전 검증과 큐가 한다). 아래 본문의 옛 이름은 그 개정 전 기록이다.

이 문서는 병렬 세션의 파일 소유권과 작업 브랜치 운영을 정한다. **브랜치·CI·승격·배포의 정본은 릴리스 프로세스**다. 2026-09-08 결정인 작업 → release → staging → main(Production)을 적용하며, 실제 배포 설정의 전환 여부는 그 문서의 상태 표로 구분한다.

v0.18.0 실행 모델

순수 문서 예외: 실행 동작을 바꾸지 않는 문서는 최신 main에서 분기해 docs/* → main PR로 직접 병합할 수 있다. 오너가 CI 생략을 요청하면 로컬·GitHub CI를 생략한다. 실행 코드·DB·workflow·배포/빌드 설정은 제외하며, 릴리스 프로세스의 문서 예외 기준을 따른다. 아래 release 경로는 제품 작업의 기본 경로다.

• 역할은 책임이며 도구·모델 이름이 권한을 결정하지 않는다. 아래 Claude Design·Codex·MacBook 등의 이름은 디자인·기능 배선·서버·iOS 책임을 가리킨다.
• 작업마다 전용 worktree와 feat/<이슈>-<slug>·fix/…·docs/… 브랜치를 만든다. **분기 기준과 PR base는 같은 목적 release/vX.Y.Z**다. v0.18.0 작업을 다른 패치에 함께 내보내지 않는다.
• 작업→release는 사전검증 후 npm run merge:request -- --pr <N>으로 요청한다. 큐가 최신 base와 고정 PR head의 후보에서 충돌·migration 순서/위험·head/base/tree·조건부 push를 확인하고 순차 병합한다. 일반 큐는 full을 실행하거나 full 기록을 만들지 않는다. release→staging 최종 후보는 hosted full CI를 실행하고 staging→main은 동일 tree의 유효한 기록과 현재 staging 배포·smoke 증거로 재사용한다.
• release 큐는 최종 병합 확인까지 슬롯을 유지하며 파일 landing:lock·heartbeat가 필요하지 않다. 개발 세션은 작업 브랜치에서 계속 개발할 수 있다. 이 release별 슬롯은 Merge Check·병합까지만 적용한다. 명시적 dry-run은 같은 슬롯에서 진단용 full을 실행하고 병합하지 않는다. 승격은 담당자가 한 후보씩 진행하고 별도 promotion 큐·전역 락·배포 완료까지 이어지는 락은 추가하지 않는다.
• 배포 전환 후 main 대상 merge:request는 사용할 수 없다. 새 배포는 main=Production, staging=staging이며 DEPLOYMENT_BRANCH_CUTOVER=true 활성화 전에는 새 Deploy를 실행하지 않는다. 릴리스 랜딩 큐와 릴리스 프로세스의 실제 상태를 확인하고 release PR의 base를 main으로 바꿔 우회하지 않는다.
• HQ 운영 문서는 범위·선행 순서·공용 자원 충돌을, ADR은 데이터 보존·기술 계약을 정한다. HQ의 상주나 일상 작업의 재승인은 요구하지 않는다. 운영 반영은 오너의 승인을 따른다.

Branches

브랜치	역할	허용 경로
main	전환 후 승인된 운영 코드의 배포 기준	staging → main 승격 PR; 순수 문서 PR 예외
staging	다음 한 릴리스 후보의 실제 환경 검증	release/vX.Y.Z → staging 승격 PR
release/vX.Y.Z	해당 버전에 포함할 작업의 통합	해당 release에서 분기한 작업 PR
feat/*, fix/*, docs/* 등	이슈별 개발·로컬 검증	분기한 release로 PR; 순수 문서는 main 분기·PR 가능
production	이전 운영 이력의 보존 ref	새 배포 대상에서 제외; 과거 이력 보존

아래 Ownership의 claude/ui·codex/frontend·codex/backend·codex-mac/ios는 역사적인 역할 표기다. 이 이름의 장기 통합 브랜치를 새로 만들거나 재사용하라는 지시가 아니다. 디자인 배송 claude/ui-* 프리뷰도 릴리스 포함·staging 검증·운영 승인을 대신하지 않는다.

Ownership

Claude Design: claude/ui

수정 허용:

• src/react/ui/**
• docs/contracts/*-props.md 또는 화면 props 계약 문서의 디자인 요구·시각 상태 제안. production 의미론은 Codex와 합의해 확정
• Claude handoff 문서

수정 금지:

• src/react/app.jsx
• src/react/services/**
• api/**
• supabase/**
• ios/**
• capacitor.config.*

Claude Design은 화면 구조, 시각적 흐름, 클래스명, CSS를 자유롭게 바꿀 수 있다. 단, 기능 연결에 필요한 data-lg-* 또는 합의된 props 계약은 유지한다. 검색·저장·라우팅 같은 production 의미론은 preview mock으로 대체할 수 있지만 screen component 안에 재구현하지 않는다.

Codex Frontend/App Core: codex/frontend

수정 허용:

• src/react/app.jsx
• src/react/appController.jsx
• src/react/sharedShell.jsx
• src/react/mobileShell.jsx
• src/react/mobileApp.jsx
• src/react/desktopApp.jsx
• src/react/controllers/**
• src/react/vite/**
• src/react/services/**
• src/react/services/supabaseAuth.ts 중 클라이언트 오류 분류와 브라우저·네이티브 세션 어댑터. Supabase 공급자 설정, 서버 인증 계약, RLS/API 의미론은 codex/backend 소유로 유지
• src/react/contracts/**
• tests/**
• src/react/ui/** 중 승인된 디자인을 바꾸지 않는 기능 통합 부분
• 화면 props 계약 문서
• React 컨테이너/테스트/아키텍처 관련 문서

시각 디자인 수정 금지:

• src/react/ui/**의 layout, CSS, typography, spacing, visual hierarchy, component composition
• ios/**
• capacitor.config.*
• api/**
• supabase/**

React 컨테이너 작업 중 시각 문제가 보이면 Claude Design에 넘긴다. 기능 문제는 Codex가 소유하며, container만으로 연결할 수 없으면 합의된 디자인을 유지한 채 UI 파일의 props/callback, controlled input, keyboard/composition event, semantic marker, 접근성, 타입을 최소 범위로 수정한다.

담당 범위 예:

• React 컨테이너 배선
• UI가 받을 props/콜백 계약
• controlled input, 검색·정규화·IME, canonical ID, 기능 상태 전이
• Claude UI와 실제 데이터 연결
• React 상태/라우팅/뒤로가기 레이어
• 컨테이너/mapper/integration 테스트와 리팩터링

Codex Backend/Platform: codex/backend

수정 허용:

• api/**
• supabase/**
• src/react/services/** 중 Supabase/Auth/API adapter
• src/react/services/supabaseAuth.ts 중 Supabase 공급자 설정, 서버 인증 계약, OAuth callback 및 RLS/API 의미론. 클라이언트 오류 분류와 브라우저·네이티브 세션 어댑터는 codex/frontend 소유
• src/react/contracts/** 중 서버/네이티브 브리지 계약
• 서버, 데이터, 인증, RLS/RPC 관련 테스트와 문서

수정 금지:

• src/react/ui/**의 마크업, CSS, 레이아웃
• ios/**
• capacitor.config.*
• React 화면 flow를 바꾸는 컨테이너 변경

담당 범위 예:

• Supabase 데이터 모델, 쿼리, RLS, RPC
• Kakao·Google·Apple/Supabase 인증 흐름
• API route
• iOS 네이티브 브리지의 웹 측 계약

MacBook iOS App: codex-mac/ios

수정 허용:

• ios/**
• capacitor.config.*
• 아래 공유 sentinel 절차를 승인받은 Capacitor dependency 변경에 한해 package.json과 사용하는 lockfile
• docs/ios-*.md
• iOS 전용 아이콘/스플래시 리소스

수정 금지:

• src/react/ui/**
• src/react/app.jsx
• src/react/services/**
• src/react/contracts/**
• api/**
• supabase/**
• index.html
• app-config.js
• public/manifest.webmanifest

iOS 작업자는 웹앱 기능을 고치지 않는다. 첫 목표는 iPhone에서 현재 Vercel 앱을 실행할 수 있는 네이티브 포장이다.

Shared merge sentinels

index.html, vite.config.mjs, package.json은 특정 역할의 상시 허용 파일이 아니라 웹 부팅·빌드·의존성 경계를 함께 바꾸는 공유 sentinel이다. 해당 파일이 필요한 Phase 또는 작업 브랜치 담당자가 수정할 수 있지만, 다음 절차를 모두 충족해야 한다.

1. 편집 전에 작업 지시와 PR에 정확한 sentinel 파일, 변경 사유, 담당 역할·Phase, 예상 빌드·배포 영향을 적는다.
2. 사용자 또는 Barbelic Headquarter가 그 sentinel 변경을 작업 범위로 명시 승인한 뒤 편집한다. 기존 이슈·세션 지시가 해당 변경을 이미 승인했다면 별도 파일별 재승인이나 HQ 상주를 요구하지 않는다. 다른 파일 작업 중 발견한 정리·포맷 변경을 함께 넣지 않는다.
3. package.json의 dependency graph를 바꾸면 사용하는 lockfile을 같은 변경으로 맞추고, 그렇지 않으면 lockfile을 건드리지 않는다.
4. merge 전에는 승인된 사유와 실제 diff가 일치하는지 확인하고 해당 build·deployment·정적 asset·dependency 계약 검증을 실행한다. 승인되지 않은 sentinel 변경은 merge하지 않는다.

장애 독립 개발 PR A~F 위임 예외

이 예외는 사용자가 merge를 Barbelic Headquarter에 위임한 장애 독립 개발 프로그램의 PR A~F에만 적용한다. 일반 sentinel의 fail-closed 기준을 낮추는 예외가 아니라, 프로그램 범위로 이미 승인된 sentinel 변경의 확인 경로만 좁혀 정의한다.

• 프로그램에 필요한 sentinel 변경은 파일마다 별도의 사용자 확인을 다시 받지 않아도 된다. 대신 PR 본문에 정확한 sentinel 파일과 변경 사유, 담당 Phase, 빌드·배포·런타임 영향, package.json 변경 시 사용하는 lockfile의 정합성, 관련 local·remote gate를 모두 기록한다.
• Headquarter는 exact base/head와 실제 diff 증거를 대조하는 exact-diff review, 파일 소유권, required verify, 정책상 요구되는 경우 migration-smoke, 별도로 요구된 full-ci가 같은 exact head에서 모두 Green일 때만 merge할 수 있다. SHA·diff·소유권·검증 증거가 달라지면 검토한 SHA의 merge를 멈추고 새 SHA에서 이 검토를 다시 수행한다. 새 증거가 모두 Green이면 아래 명시적 범주가 아닌 한 별도의 사용자 확인 없이 기존 merge 위임이 계속된다.
• 사용자(owner)에게 즉시 escalation·report해야 하는 경우는 다음 여섯 범주뿐이다.
  1. Red gate 우회·완화 제안. check skip, required-check 약화, 테스트·품질 baseline 약화를 모두 포함한다. 제안 즉시 멈추고 보고·질문하되 기본 판단과 구현 조치는 DENY이며, owner가 확인해도 해당 우회를 merge할 수 없다.
  2. 테이블·컬럼 삭제, 타입 축소, 데이터 삭제·변환을 포함한 파괴적 DB migration.
  3. 유료 옵션 또는 요금제 변경을 포함해 비용이 발생하는 모든 결정.
  4. 보안 불변식, completion 조건 또는 stop condition 완화.
  5. Phase 3 iOS local bundle 결정.
  6. backup track 밖 cloud·secret 설정.
• 2~6번은 owner의 명시 확인 뒤 진행할 수 있는 다섯 approval-capable 예외다. 확인 뒤에도 해당 diff의 exact-diff review와 소유권, 모든 required gate는 그대로 Green이어야 한다. 1번과 프로그램 밖 변경의 동반 merge는 승인 가능한 예외가 아니다.

Workflow

작업 이슈의 목적 릴리스를 확인한 뒤 새 브랜치를 만든다. 아래 버전과 이름은 예시이며, 원격 release가 없으면 먼저 출시 범위를 정하고 생성한다.

git fetch origin
git switch -c feat/<issue>-<slug> origin/release/v0.17.3
# 변경·관련 테스트·커밋·push 후 PR base를 release/v0.17.3으로 지정한다.
npm run merge:request -- --pr <N>

요청은 clean worktree와 로컬 HEAD = PR head를 요구한다. 큐가 슬롯을 얻은 뒤의 최신 release를 후보에 반영하므로 앞선 PR이 먼저 들어가도 그 결과부터 최종 CI를 실행한다. 충돌·CI 실패·실행 중 head/base 변경은 병합하지 않으며 담당자가 수정 후 다시 요청한다. 이미 머지된 작업 브랜치를 재사용하거나 git checkout -B로 기존 작업을 초기화하지 않는다.

출시된 main의 패치는 다음 release에 반영한다. 미래 release 전체를 앞선 패치에 합치지 않는다. staging에는 다음 출시 한 후보만 두고, 발견된 수정은 작업 → 해당 release → staging 경로로 반영한다. 두 승격 PR의 조건은 릴리스 프로세스를 따른다.

Merge Gate

Local-first and integration PR policy

실행 시점은 릴리스 프로세스, 검사 구성과 현재 구현은 CI 실행 흐름, 명령은 로컬 CI를 따른다.

• 작업 → release: GitHub 큐의 같은 슬롯 안에서 최신 release base와 고정 PR head를 합친 merge commit에 full 로컬 CI·docs/admin 빌드를 실행한다. 통과 후 head/base·라벨·clean 상태·tree를 재확인하고 예상 base일 때 검증한 commit 그대로 fast-forward push한다. 개별 세션의 사전 테스트나 verify-only 결과로 이를 대체하지 않는다.
• release → staging: 현재 staging과 합쳐질 결과의 GitHub full CI. 성공 후 병합하면 staging DB → Edge → frontend → smoke로 자동 배포한다(배포 연결 전환 후).
• staging → main: 현재 main과 합쳐질 결과의 GitHub full CI를 다시 실행한다. 같은 코드의 staging 배포·확인과 오너의 운영 반영 승인이 있어야 병합한다.
• 두 승격은 merge commit으로 이력을 보존한다. 검증한 base/head가 바뀌면 다시 최신화·검증하며, 병합 push에서 full CI를 중복하지 않는다. DB 쓰기를 포함한 배포는 환경별로 직렬 실행하고 중간 취소하지 않는다.
• 필수 검사는 최신 base를 요구하도록 전환한다. 현재 main의 verify·landing-queue 요구나 기존 PR CI를 이 문서만 근거로 우회하지 않는다. 새 경로의 workflow·보호 규칙은 함께 전환해야 한다.

과거 PR A~F 프로그램에 한정된 위임 기록

다음 두 문단은 당시 프로그램의 위임·관찰 범위를 보존한 기록이다. 일반 release 작업의 CI 실행 시점과 배포 브랜치는 위 정책을 따른다.

장애 독립 개발 프로그램의 PR A~F는 위 sentinel 예외와 동일한 범위에서 사용자가 Headquarter에 exact merge를 위임한다. Headquarter는 PR 본문의 사유·담당 Phase·영향·lockfile 정합성·관련 gate 증거와 exact base/head/diff·소유권, required verify, 정책상 요구되는 경우 migration-smoke, 별도로 요구된 full-ci Green을 확인한 뒤 Ready 전환과 exact merge를 수행할 수 있다. SHA가 바뀌면 그 SHA의 merge는 멈추고 새 exact head를 다시 검토·검증하며, 모두 Green이면 위 다섯 owner 확인 예외를 제외하고 새 사용자 merge 확인 없이 위임이 이어진다. 하나라도 Red이거나 증거가 불완전하면 merge하지 않는다.

정상 post-merge 완료 요약은 constituent merge나 중간 Ready·merge action마다 반복하지 않고 integration PR 완료 뒤 한 번만 보고한다. 이 요약에는 PR과 merge SHA, 확인한 remote main, 자동 main verify/check 결과, Vercel Production, post-deploy smoke 결과를 포함한다. 단, Production 관찰 중 deployment 실패, post-deploy smoke anomaly, 지연 관찰 anomaly를 포함해 이상이 발견되면 완료 요약을 기다리지 않고 exact 첫 checkpoint를 즉시 보고한다. 이 보고에는 route 진입 전인지 제품 경로 안인지, 후속 실패가 cascade인지, 데이터·배포 mutation과 rerun 여부를 포함하고 임의 rerun·재배포·DB 조치 없이 멈춘다.

목적 브랜치에 합치기 전 변경 범위에 맞춰 확인한다.

• npm run check 통과
• npm run build 통과
• npm run check:unused 통과
• 변경 파일이 해당 브랜치의 허용 범위 안에 있음
• src/react/ui/**의 시각 변경은 Claude Design 산출물 또는 명시 승인된 UI 작업임
• src/react/ui/**의 Codex 변경은 디자인 불변의 최소 기능 배선이며 관련 회귀 테스트가 있음
• src/react/controllers/**, src/react/vite/**, supabaseAuth.ts의 클라이언트 오류 분류·세션 어댑터 변경은 Codex Frontend/App Core 작업임
• api/**, supabase/**, src/react/services/**의 공급자 설정·서버 인증·데이터 계약 변경은 Codex Backend/Platform 작업임
• ios/**, capacitor.config.*, Capacitor dependency 변경은 iOS 작업임
• index.html, vite.config.mjs, package.json 변경은 공유 sentinel 사전 승인·사유·담당 역할·검증 절차를 모두 충족함
• 의도치 않은 app-config.js, public/manifest.webmanifest 변경이 없음

허용 범위 밖 파일이 바뀌었으면 merge하지 않는다. 먼저 이유를 설명하고 사용자 확인을 받는다.

단, 장애 독립 개발 프로그램의 PR A~F에서 파일 소유권이 어긋난 경우에는 임시 사용자 승인으로 우회하지 않는다. merge를 중단하고 해당 변경을 제거하거나 책임 있는 Phase·owner에게 재할당한 뒤 exact diff와 gate를 다시 검증한다.

Conflict Policy

• 시각 디자인 충돌: Claude Design 기준으로 판단한다.
• 같은 UI 파일이라도 props/event/result 배선과 기능 의미론 충돌: Codex Frontend/App Core 기준으로 판단한다.
• React 컨테이너/props/테스트 충돌: Codex Frontend/App Core 기준으로 판단한다.
• supabaseAuth.ts의 클라이언트 오류 분류·세션 어댑터 충돌: Codex Frontend/App Core 기준으로 판단한다.
• Supabase 공급자 설정·서버 인증 계약·데이터/저장/RLS/API 충돌: Codex Backend/Platform 기준으로 판단한다.
• iOS/Xcode/Capacitor 충돌: MacBook iOS App 기준으로 판단한다.
• main의 안정성이 의심되면 merge를 멈추고 별도 hotfix 브랜치를 만든다.

React Container Merge Policy

src/react/app.jsx는 UI 파일이 아니라 앱 컨테이너다. Claude Design은 보통 src/react/ui/**만 수정하지만, 새 UI-flow를 실제 앱에 연결하려면 Codex가 app.jsx에서 props, callbacks, routing state, history handling, data hydration을 배선해야 한다.

목적 release와 디자인 작업 브랜치의 app.jsx가 충돌하면 한쪽을 통째로 고르지 않는다. 다음 기준으로 합성한다.

• 목적 release의 app.jsx는 기능/백엔드/버그픽스의 기준으로 본다.
  • Supabase/RPC/RLS 이후 저장·삭제 로직
  • iOS OAuth/WebView 연동
  • 데이터 mapper/repository 연결
  • PR/세션 조회 등 이미 고친 기능 회귀 방지
  • 테스트가 기대하는 container behavior
• 디자인 브랜치의 app.jsx는 Claude UI-flow 배선 참고자료로 본다.
  • 새 화면 진입/복귀 흐름
  • Claude UI가 요구하는 props와 callbacks
  • Ui* 컴포넌트의 contract 변경
  • 홈/운동일지/기록/운동 플로우의 화면 전환 의도
• 사용자가 승인한 최신 화면 이동 UX는 Claude Design 의도를 우선한다.
• 저장, 삭제, 인증, 원격 데이터 로딩, 테스트 안정성은 목적 release에 통합된 기능 구현을 우선한다.
• src/react/ui/**의 시각 디자인은 직접 바꾸지 않는다. 기능 배선 문제는 합의된 디자인을 보존하는 최소 수정으로 Codex가 해결하고, 시각 문제가 발견되면 Claude 확인 큐나 handoff 문서에 남긴다.

예: Claude가 UiDaySummary, lockedStart, backfill, PlanLite.draft를 추가했고, 목적 release에는 iOS/RPC/PR 세션 점프 수정이 있다면, 그 저장·인증·PR 기능은 유지하면서 Claude의 새 UI-flow props를 app.jsx에 배선한다.

Handoff Prompt

다른 세션에 넘길 때는 다음을 포함한다.

docs/process/release-process.md와 docs/process/branch-workflow.md를 먼저 읽어.
목적 릴리스는 release/vX.Y.Z야. 이 브랜치에서 분기하고 같은 브랜치로 PR을 열어.
작업 → release는 로컬 CI, release → staging과 staging → main은 각각 GitHub full CI야.
release PR은 merge:request -- --pr <N>으로 요청해. GitHub 큐가 CI·병합 전체를 잠그고 self-hosted runner가 최종 full CI를 실행해. 파일 landing:lock은 필요 없어.
release-landing-queue.md에서 실제 workflow·보호 규칙 활성화 상태도 확인해.
실제 배포 연결은 릴리스 프로세스의 전환 상태를 확인해.
React 컨테이너/props/테스트는 기능 배선 역할, Supabase/Auth/API는 서버 역할의 책임이야.
역할은 파일 경로뿐 아니라 변경의 성격으로 판단해. Claude는 시각 디자인,
Codex는 production 기능과 배선을 소유해. Codex가 ui/**를 고칠 때는 승인된
디자인을 바꾸지 않는 최소 props/event/result 배선만 허용돼.
네 작업 브랜치와 허용 범위를 지켜.
허용 범위 밖 파일을 고쳐야 할 것 같으면 멈추고 이유를 보고해.
작업 후 npm run check를 통과시키고 변경 파일 목록을 보고해.