profile-sync

name	profile-sync
description	blablalink 로그인 세션으로 내 계정의 실제 육성 상태를 받아 육성 프로필(profiles/<이름>.json)로 갱신한다. "내 육성 데이터 가져와" "내 스펙 갱신해" 요청에 쓴다. 게임 마스터 데이터 갱신은 char-scrape, 신규 캐릭터 등록은 char-add를 쓴다.

profile-sync

내 계정의 사적인 육성 상태를 받아 profiles/<이름>.json으로 만든다. 받아온 프로필로 계산하는 건 이 skill이 아니라 러너의 --profile 옵션이다(아래 §쓰는 쪽).

char-scrape와 성격이 정반대다. 저쪽은 모두가 공유하는 게임 마스터 데이터를 공개 CDN에서 받아 커밋 대상으로 갱신하고, 이쪽은 한 계정의 개인 데이터를 로그인 세션으로 받아 로컬에만 둔다. 문서·절차·gate를 섞지 않는다.

절대 규칙

• scraper/.session_cookie는 계정 접근권이다. 내용을 출력하지 않고, 커밋하지 않고, 어떤 파일로도 복사하지 않는다.
• profiles/는 통째로 gitignore다. 프로필·원시 응답을 커밋 대상에 올리지 않는다.
• 프로필 수치를 보고할 때 openid를 그대로 노출할 이유가 없으면 생략한다.

절차

1. python scraper/profile_fetch.py (프로필 이름을 지정하려면 --name <이름>).
2. 세션 만료(game not login)면 아래 §쿠키 확보를 유저에게 안내하고 멈춘다. 에이전트가 대신 로그인할 수 없다.
3. 실행 로그의 경고를 하나도 빠뜨리지 말고 유저에게 그대로 옮긴다. 특히:
   • 동기화 소대 밖 N종 — 미보유 판정이 아니다. 소대에 안 넣어 인게임 레벨이 1인 것뿐이고, 레벨은 정책이 정하므로 계산에는 영향이 없다. 다만 그쪽은 스킬·장비 투자가 없는 경우가 많다 — 유저가 "얘 왜 딜이 바닥이야"라고 하면 스킬 레벨부터 확인한다.
   • 모르는 재활용 연구실 tid — 신규 역할군·기업이다. CONSOLE_TIDS에 사람이 추가해야 하며, 그전까지 그 연구실은 콘솔 계산에서 빠진다.
   • 애장품 단계 3 미만 — 그 단계의 스킬 판본으로 계산된다(docs/PARSING.md §애장품). 판본이 아직 파싱 안 됐으면 시뮬이 어느 슬롯이 없는지 알리며 끊는다.
   • 미매핑 오버로드 옵션 타입 — 신규 옵션이다. profile_fetch.py의 FUNC_TO_EQUIP에 사람이 추가해야 하며, 그전까지 그 옵션은 조용히 빠진 채 계산된다.
   • 옵션 수치가 equipment_skills 표에 없다 — 손으로 관리하는 data/base_stat_tables/equipment_skills.json이 게임과 어긋났다는 뜻이다. 게임 쪽이 정본이므로 표를 고치고 _verify에 근거를 남긴다.
4. 요약(보유 종수 · 소장품 미장착 · 장비 미장착 · 콘솔 상태)을 보고하고 멈춘다.

변환 규칙만 바뀌었을 때는 재수집이 필요 없다 — --from-raw가 profiles/<이름>.raw.json으로 프로필만 다시 만든다(로그인 세션 불필요, CDN 매핑만 받는다). 결과를 먼저 보고 싶으면 --out <딴이름>으로 써 본다.

쿠키 확보 (최초 1회, 유저가 직접)

유저 데이터 API는 전부 로그인 세션을 강제한다. 익명·공개 조회 API는 없다(실측). 인증은 순수 쿠키라, 한 번 받아두면 이후 수집은 브라우저 없이 HTTP로 돈다.

1. blablalink.com 로그인 + 게임 계정 연동
2. DevTools > Network에서 api.blablalink.com 요청의 Cookie: 헤더 전체 복사 (핵심은 game_token game_openid game_gameid)
3. scraper/.session_cookie에 한 줄로 저장

만료되면 game not login(code 300001)이 뜬다 → 2~3만 다시 한다.

프로필에 들어가는 것 / 안 들어가는 것

항목	프로필	근거
돌파·코강·호감도 · 스킬 1/2/3 레벨	○	레벨과 달리 인게임에서 고정되지 않는다
레벨	✗	정책이 정한다 (§레벨 정책). 인게임 레벨은 동기화 소대 편성 상태일 뿐이다
장비 4부위 (기업 강화 / 일반 T1~T9 / 미장착)	○	미장착은 tier: "없음" — 기업 강화0으로 적으면 부위당 수천 atk이 유령으로 붙는다
오버로드 합산	○	12슬롯 직접 순회 (§엔드포인트)
오버로드 부위 경계 (_overload)	○	계산에는 안 들어가는 _ 키다(합산 쪽이 정본). 어느 줄이 어느 부위인지는 더 굴릴지 판단할 때 필요하다 — 굴릴 부위는 배경에서 빼야 하므로(웹앱 레포 overload/README.md §굴릴 부위) 웹앱 오버로드 화면이 이걸 읽는다
소장품 / 애장품	○	슬롯 하나를 공유한다. 애장품은 스탯이 SR15와 같아 SR15로 적고, 단계는 favorite_stage 0~3으로 따로 담는다 (스킬 판본을 정한다)
큐브	✗	API는 장착 중인 것만 준다 — 보유 큐브 목록을 주는 라우트는 프론트엔드 전체에 없다(청크 439개 전수 조사). 큐브는 자유롭게 갈아끼우므로 육성이 아니라 케이스가 정하는 축이며, 관찰분은 _account.cubes에 보유 하한으로만 남아 "그 레벨로 갖고 있는가" 경고에만 쓰인다
콘솔	○	Game/GetUserProfileOutpostInfo의 recycle_room_researches. tid 1001=공통 · 11xx=역할군 · 12xx=기업
컨트롤·버스트 패턴	✗	육성이 아니라 운용이다. data/char_defaults.json이나 호출부에 둔다 — 프로필에 들어오면 로드가 끊는다

쓰는 쪽 — 프로필로 계산하기

수집과 계산은 따로 요청받는다. 유저가 "내 스펙으로 계산해"라고 하면 재수집 없이 기존 프로필로 돌린다. 프로필이 오래됐으면 _meta.fetched_at을 근거로 갱신을 제안만 한다.

python -m runner.sim "<스쿼드>" --profile me                     # 단발 (레벨 400 고정)
python -m runner.sim "<스쿼드>" --profile me --profile-level sync # 동기화 소대 레벨로
# 프로필에 없는 이름은 미육성으로 계산된다 (돌파 0 · 스킬 1/1/1 · 장비 미장착)

보고서는 스펙 JSON에 "profile": "me"(필요하면 "profile_level": "sync")를 넣는다.

레벨 정책

인게임 캐릭터 레벨은 동기화 소대에 넣었는지에 달린 편성 상태지 육성 상태가 아니고, 솔로레이드는 레벨이 400으로 고정된다. 그래서 프로필은 레벨을 담지 않고 러너가 정한다.

정책	레벨
fixed (기본)	기본 스펙 레벨 400	솔로레이드 기준. 고정 스펙과 레벨이 같아 육성 차이만 남는 비교가 된다
sync	_account.synchro_level	동기화 소대 레벨. 소대 밖 캐릭터도 같은 값으로

• 프로필에 아예 없는 이름(미보유·수집 후 나온 신캐)은 미육성으로 계산된다 — 돌파 0 · 스킬 1/1/1 · 장비 미장착 · 소장품 없음, 레벨과 콘솔만 다른 캐릭터와 같다. 고정 스펙으로 떨어뜨리면 만렙 가상 캐릭터가 섞여 "내 계정 기준"이 거짓말이 되므로 그렇게 하지 않는다. 대체 목록은 결과에 실린다. 동기화 소대 밖 캐릭터는 프로필에 있으므로 여기 해당하지 않는다 — 다른 캐릭터와 똑같이 계산된다.
• 프로필로 낸 결과는 고정 스펙 결과와 총딜을 직접 비교하지 않는다. 러너가 그 경고를 강제로 싣는다 — 유저에게 답할 때 그 줄을 그대로 옮긴다.
• 회귀 하네스(runner/snapshot.py)는 프로필을 받지 않는다. golden baseline은 고정 스펙 전용이다.

레이어 구조와 이탈 보고 규칙은 docs/HARNESS.md §2.5층이 정본이다.

엔드포인트

API (/api/game/proxy/)	파라미터	준다
Game/GetUserCharacters	intl_open_id, nikke_area_id	니케 로스터: name_code·유효 레벨·grade·core·combat
Game/GetUserCharacterDetails	+ name_codes[]	스킬레벨·장비4부위(티어·강화·옵션3)·큐브·소장품/애장품·호감도 + state_effects(옵션 해석)
Game/GetUserProfileOutpostInfo	intl_open_id, nikke_area_id	전초기지: recycle_room_researches(= 콘솔)·synchro_level·outpost_battle_level

라우트 전체 목록은 프론트엔드 번들 assets/v4-*.js에 문자열로 들어 있다. 새 항목이 필요하면 거기서 찾는다(/Get... 형태). 조사 시점(2026-08-15) 기준 큐브 보유 목록 라우트는 없다.

실측으로 확인한 사실:

• lv <= 1은 미보유 판정이 아니다. 동기화 소대 밖이라 인게임 레벨이 안 오른 것뿐이다. 실측(2026-08-15): 로스터 192종 중 lv 1이 21종인데 그 수가 synchro_nonempty_slot_count(171)의 여집합과 정확히 일치했고, 유저 확인 결과 전원 보유 중이었다(소대에 안 넣었을 뿐). 그래서 로스터 전원을 담고 _unsynced 플래그만 세운다. 레벨은 정책이 정하므로 이 플래그는 계산에 영향이 없다.

  이전 구현이 lv > 1을 보유 판정으로 써서 보유 캐릭터 20종이 통째로 빠져 있었다. 같은 실수를 반복하지 않도록 여기 남긴다 — 동기화 소대는 보유와 무관하다.

• name_code → resource_id → 우리 캐릭명: CDN character_id_map.json + nikke_scraped.json의 id.
• 오버로드 합산: state_effects는 옵션 id로 중복 제거된다(같은 옵션이 2부위면 1번만 등장) → 합산에 못 쓴다. 12개 슬롯을 직접 순회하고, state_effects는 옵션id → (타입, 값) 사전으로만 쓴다.
• favorite_item_tid는 소장품(R·SR)과 애장품(SSR)이 공유하는 슬롯이다. 등급은 CDN favorite_rare_map.json이 준다. SSR 애장품의 플랫 스탯·소장품 스킬 레벨은 SR15와 완전히 같고(favorite_{id}.json의 atk·hp·def 배열이 단계와 무관하게 SR15 값, level1=4), favorite_item_lv 0/1/2가 단계 1/2/3이다.
• 호감도 0(미투자)은 호감도 표가 1부터라 1로 클램프.

CDN 난독화 경로 규칙은 ../char-scrape/SCRAPER.md §난독화 경로 규칙이 정본이다.