career-record

name	career-record
description	개인 이력·경력·활동·스킬·포트폴리오 기록을 갱신하는 스킬. 저장소 판정 → 기존 항목 형식 대조 → 정렬 위치 결정 → 이미지 이중 배치 → 파생 데이터 동기화 → 실제 페이지 렌더 확인까지의 워크플로를 다룬다. 사용자가 "이직했어", "회사 옮긴 거 반영해줘", "이 프로젝트 포트폴리오에 추가해줘", "스킬에 X 추가", "경력 기간 수정", "이력서 최신화", "about 페이지 내용 바꿔줘", "홈 소개문 고쳐줘", "회사명이 잘못 나와" 등 개인 기록 데이터를 추가·수정·삭제하는 요청을 하면 반드시 이 스킬을 사용할 것. 기록을 어떻게 보여줄지(컴포넌트·레이아웃·스타일)를 바꾸는 작업은 ui-component가 담당하며, 기록 자체가 바뀌지 않는 대화라면 이 스킬을 적용하지 않는다.

Career Record (개인 기록 갱신 워크플로)

이 데이터는 타입 검사도 테스트도 잡아주지 않는 층에 있다(→ AGENTS.md §7). 핵심 원칙은 "바꿀 문자열의 출처가 한 곳이라고 단정하지 않는다".

0. 대원칙

• 이미지는 두 곳에 함께 넣는다. 사이트가 서빙하는 사본과 Storybook 정적 사본이 각각 커밋돼 있다(→ §7). 한 곳만 넣으면 한쪽에서는 보이고 다른 쪽에서는 깨지며, 어느 쪽이 깨졌는지는 화면만 보고 구분되지 않는다. 반쪽 배치는 만들지 않는다.
• 배열은 자동 정렬되지 않는다. 최신 항목은 맨 위에 넣는다. 렌더가 배열 순서를 그대로 쓴다(→ §7). append하면 새 경력이 가장 오래된 항목 아래에 붙는다. (나쁜 예: 배열 끝에 추가 / 좋은 예: 기간을 보고 올바른 인덱스에 삽입)
• 경력 항목의 필드 이름과 화면 위치는 반대다. 제목 줄에는 role이, 캡션에는 회사명(title)이 나온다(→ §7). "회사명이 잘못 나온다"는 요청에 회사 필드를 고치면 틀린다. 손대기 전에 어느 필드가 어디에 렌더되는지 코드로 확인한다.
• "스킬"은 서로 무관한 세 어휘를 가리킨다. URI 맵의 키, /about에 실제로 표시되는 카테고리 문자열, 포트폴리오 항목의 자유 문자열(→ §7). 어느 것을 말하는지 확정하기 전에 손대지 않는다. /about에 보이길 원하면 답은 카테고리 하나뿐이다.
• 이 파일들의 오타와 이름 불일치는 데이터가 아니라 API다. 오타 난 export 이름, 낡아 보이는 항목 값 — 기록 갱신 작업 중에 함께 고치지 않는다. 이름을 고치면 임포트가 전부 깨지고, 값을 고치면 사용자가 의도하지 않은 사실이 바뀐다. 눈에 걸리면 지적만 하고 그대로 둔다.

1. 저장소 판정

래더:

1. 바꿀 문자열을 레포 전체에서 그대로 검색해 실제 출처를 전부 찾는다 (grep에 --exclude-dir=.claude → §1).
2. 검색으로 안 나오면(신규 항목) 같은 종류의 기존 항목이 사는 파일을 §7의 표에서 고른다.
3. 판정이 갈리면 사용자에게 한 줄로 묻는다.

게이트: 출처를 하나도 빠뜨리지 않았고(한 곳이라고 단정하지 않았다), 직함·역할·자기소개류라면 §7이 명시한 중복 저장소와 하드코딩 예외를 둘 다 확인했다.

막히면: 검색으로 출처가 안 잡히면 §8 DEV로 해당 페이지를 열어 그 문자열이 화면 어디에 나오는지 부터 확인한다. 파일 추측으로 넘어가지 않는다.

2. 형식 대조

게이트: 새 항목의 키 집합이 같은 배열의 인접 항목과 정확히 일치하고, 기간 문자열이 그 배열의 형식을 그대로 따르고(포스트 날짜 형식과 다르다 — §6 vs §7), React key로 쓰이는 필드 값이 배열 안에서 유일하다. (나쁜 예: 기간을 포스트 날짜 형식으로 씀 / 좋은 예: 인접 항목을 복사해 값만 바꿈)

막히면: 새 필드가 필요하면 그 배열의 모든 항목에 넣을지 한 항목에만 넣을지 먼저 결정한다. 일부에만 넣으면 파생 타입이 조용히 달라진다. 결정을 못 하면 필드를 추가하지 않고 기존 필드로 표현한다.

3. 정렬 위치

게이트: 새 항목이 기간 기준 올바른 자리에 있고, §8 DEV에서 렌더된 순서가 배열 순서와 같음을 눈으로 확인했다.

4. 이미지 (해당 시)

래더:

1. 이미지 없이 갈 수 있으면 빈 배열로 두고 끝낸다 — 전례가 다수다.
2. 넣어야 하면 §7의 두 경로에 같은 파일을 넣고, 해당 경로 맵 모듈에 키를 추가하고, 데이터 항목이 그 맵을 참조하게 한다.
3. 두 곳 중 한 곳에만 넣을 수밖에 없는 상황이면 이미지를 넣지 않는다.

게이트: 두 경로의 파일 목록이 일치하고, 맵의 키 수와 실제 파일 수가 같고, 페이지에서 이미지가 실제로 표시된다.

5. 파생 동기화

게이트: 직함·소속·소개 문장이 바뀌었으면 §7의 다른 저장소(SEO 메타의 설명·키워드, 홈 소개문, 하드코딩된 학력 문장)를 함께 검토했고, 바꾸지 않기로 한 것도 명시적으로 결정하고 사용자에게 알렸다.

(나쁜 예: 경력 배열만 고치고 끝 / 좋은 예: "경력은 갱신했습니다. SEO 설명과 홈 소개문에도 예전 직함이 남아 있는데 같이 바꿀까요?")

6. 검증

래더:

1. §8 TYPECHECK과 §8 LINT. 포트폴리오를 건드렸으면 §7이 명시한 파생 타입 제외 사항 때문에 어떤 배열을 고쳤는지에 따라 오류가 안 날 수도 있다는 점을 감안한다.
2. §8 DEV로 §7이 지목한 소비 페이지(/about, /project, /)를 열고 바뀐 항목이 의도한 위치에 의도한 문자열로 보이는지 확인한다.
3. dev가 불가하면 타입체크만 하고 렌더는 ⚠️ 미검증으로 보고한다.

게이트: 타입체크 0 에러, 소비 페이지 육안 확인, 콘솔에 key 중복 경고 없음.

주의: §8 TEST는 이 영역을 거의 커버하지 않는다. 스펙은 대부분 toBeTruthy()만 본다. "테스트 통과"를 근거로 쓰지 않는다.

7. 세션 종료 시

바꾼 저장소와 항목, 정렬 위치, 이미지 배치 결과, 동기화하지 않기로 결정한 파생 데이터 목록, 검증 상태(✅/⚠️)를 요약한다.