[P-Reinforce] Global knowledge consolidation, massive deduplication (5,249 files), and high-density wikification (45 nodes)

2026-05-05 15:28:22 +09:00
parent a7d1e60ccf
commit dd01e01bea
3430 changed files with 42739 additions and 52263 deletions
@@ -1,103 +0,0 @@
-# Skybound Player Airframe and 8 Stage Boss Continuity Rework
-
-작성일: 2026-04-25 09:51 KST
-
-## 요청 요약
-
- 사용자 기체가 엔진에서 그린 도형 조립처럼 보여 시각적 완성도가 낮아 보이는 문제를 개선한다.
- Stage 1 클리어 후 Stage 2로 넘어가는 흐름이 결과 화면으로 끊겨 게임이 단절되는 문제를 개선한다.
- Aero Fighters처럼 보스를 처치하고 같은 런 안에서 다음 스테이지로 자연스럽게 이어지는 구조를 만든다.
- 총 8개 스테이지를 유지하고, 스테이지가 올라갈수록 난이도가 올라가도록 보스 HP, 파츠, 패턴을 재조정한다.
- 각 스테이지 보스가 서로 다른 공격 패턴을 체감할 수 있도록 실행부를 보강한다.
-
-## 확인한 문제
-
-### 플레이어 기체 렌더링
-
- `GameRenderer.renderPlayer()`에서 플레이어 스프라이트 위에 랜덤 원형 엔진 글로우를 직접 그려서, 기체 뒤쪽이 매 프레임 흔들리는 임시 도형처럼 보였다.
- `renderWeaponAttachments()`에서 일부 장착 무기를 `fillRect`, `strokeRect`, 랜덤 원형 플래시로 그려서 톤앤매너에 맞는 완성형 파츠가 아니라 디버그 박스처럼 보일 수 있었다.
- 특히 Hyper Sonic Vulcan, Gatling fallback, Missile Pod fallback이 사용자 기체 실루엣과 잘 섞이지 않았다.
-
-### 스테이지 전환
-
- 보스 처치 후 `STAGE_CLEAR`가 되고, 300프레임 뒤 `BOSS_ACTION NEXT_STAGE` 이벤트가 발생한다.
- 기존 `useGameEngine`은 이 이벤트를 곧바로 `finishMission('CLEAR')`로 연결했다.
- 그 결과 Standard 캠페인에서도 Stage 1 보스 처치 후 결과 화면으로 끊기고, 다음 스테이지는 별도 런처럼 느껴졌다.
-
-### 보스 패턴
-
- `bossActions.ts`에는 Stage 1부터 Stage 8까지 액션 테이블이 있다.
- 하지만 `BossSystem.executePattern()`은 일부 액션만 처리하고 있었기 때문에, 실제 전투에서는 많은 액션이 기본 단발 탄으로 떨어질 수 있었다.
- `StageDirectorSystem.instantiateBoss()`의 보스 파츠 turretId가 `T-CORE`, `T-WING`, `T-HEAVY`처럼 실제 `TURRET_CATALOG`에 없는 값이라 파츠 포탑이 의도대로 발사되지 않을 수 있었다.
- 기존 보스 HP는 Stage 2부터 `5000 * currentStage`로 급격히 올라가 캠페인 커브가 자연스럽지 않았다.
-
-## 적용한 변경
-
-### 플레이어 기체 완성도 개선
-
- 플레이어 엔진 글로우를 랜덤 원형에서 고정된 마기테크 추진 플룸으로 변경했다.
- 스프라이트 크기를 72px에서 78px로 약간 키워 중심 기체의 존재감을 높였다.
- `drawMagitechPod()` 헬퍼를 추가해 장착 무기를 작은 마기테크 포드 형태로 통일했다.
- Vulcan, Gatling fallback, Missile Pod fallback을 박스 도형 대신 다크 블루 메탈 바디, 시안/옐로/핑크 액센트, 라운드 포드 실루엣으로 렌더링한다.
- 장착 파츠의 랜덤 플래시를 줄이고 프레임 기반 pulse로 바꿔 덜 튀고 더 의도적으로 보이게 했다.
-
-### 연속 캠페인 전환
-
- Standard 캠페인에서 Stage 1-7 보스 처치 후 `finishMission`을 호출하지 않고, 같은 엔진 런 안에서 다음 스테이지로 전환하도록 변경했다.
- 전환 시 다음 작업을 수행한다.
- `currentStage` 증가
- `campaignStageIndex` 저장
- `StageDirectorSystem.advanceToStage()`로 새 타임라인 로드
- 활성 총알, 적, 파티클 풀 정리
- 스포너 큐 초기화
- 보스, 탄막, hazard, airdrop, exp gem, vortex 정리
- `INTRO` 페이즈로 재시작
- 체력 25% 회복과 120프레임 무적 부여
- Stage 안내 텍스트와 HQ comms 출력
- Stage 8 보스 처치 시에는 `GAME_COMPLETE`로 결과 화면에 진입한다.
- Blitz 모드는 기존처럼 단일 전투 클리어로 유지한다.
-
-### 8스테이지 보스 커브
-
- 보스 HP를 선형 폭증에서 완만한 곡선형 성장으로 변경했다.
- Stage 1은 낮게 시작하고, Stage 8은 누적 성장과 보스 패턴 난이도를 고려해 높은 난이도를 갖도록 설계했다.
- 보스 파츠 HP도 같은 stage curve를 사용해 코어, 날개, 포탑이 함께 성장한다.
- 각 스테이지에 실제 `TURRET_CATALOG`에 존재하는 turretId loadout을 지정했다.
-
-### 보스 패턴 실행 보강
-
- 다음 액션들이 실제 탄막/기믹으로 실행되도록 매핑했다.
- `FAN_PART`, `DASH_PART`: 부채꼴 조준 사격
- `SIDE_WAVE`: 좌우 측면 웨이브
- `ZONE_BOMB`: 안전 구역 압박과 링 탄막
- `WALL_WAVE`: 틈이 있는 벽 형태 탄막
- `MISSILE_BARRAGE`, `HOMING_CHASE`: 유도성 탄막
- `CROSS_CHASE`: 네 방향 교차 추격 탄
- `SPIRAL_WEB`, `REVOLVING_FLAME`: 나선 탄막
- `BURST_SPLITTER`: 분열형 부채 탄
- `GEAR_STORM`: 고밀도 나선과 링 조합
- `PRECISION_LOCK`, `SNIPE_GRID`, `LASER_AIM`, `LASER_SWEEP`: 크로스헤어 기반 고속 압박
- `TELEPORT_STRIKE`: 보스 위치 변경 후 기습 사격
- `GIMMICK_PULSE`, `CC_REVERSE`, `ZONE_COLLAPSE`: 중력장/페이즈존 기믹과 링 탄막
- `ULTIMATE_SYMPHONY`: 기존 고난도 복합 패턴 유지
-
-## 수정 파일
-
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/GameRenderer.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/hooks/useGameEngine.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/StageDirectorSystem.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/BossSystem.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/EntityManager.ts`
-
-## 검증
-
- `npm run build` 성공
- Vite 경고: `/sprites/player.png referenced in /sprites/player.png didn't resolve at build time`
- 위 경고는 기존 런타임 경로 관련 경고이며 이번 변경으로 인한 빌드 실패는 아니다.
-
-## 후속 플레이테스트 포인트
-
- Stage 1 보스 처치 후 결과 화면 없이 Stage 2 INTRO로 자연스럽게 이어지는지 확인한다.
- Stage 8 보스 처치 후 `GAME_COMPLETE` 결과로 진입하는지 확인한다.
- 장착 무기 파츠가 기체와 과하게 분리되어 보이지 않는지 확인한다.
- Stage 3 이후 `ZONE_BOMB`, `WALL_WAVE`, `HOMING_CHASE`, `PRECISION_LOCK` 계열이 회피 목적을 명확히 만드는지 확인한다.
@@ -1,75 +0,0 @@
-# Skybound Skill Concept and Hangar Layout Overlap Fix
-
-작성일: 2026-04-25 10:09 KST
-
-## 요청 요약
-
- 스킬 업그레이드 후 화면에 긴 라이트 기둥만 보이는 문제가 있어 스킬 개념과 연출을 수정한다.
- HUD/UI 관점에서 왼쪽에 여러 UI가 겹쳐 나오는 문제가 있어 필요하면 전체적으로 재설계한다.
-
-## 확인한 문제
-
-### Hyper-Sonic Vulcan 컨셉 불일치
-
- `Hyper-Sonic Vulcan`은 이름상 고속 벌컨/캐논 계열인데 실제 구현은 영구 지속되는 긴 레이저 빔이었다.
- `GameRenderer`가 플레이어 기준으로 화면 끝까지 이어지는 두꺼운 시안 빔을 그려서, 스킬이 무기라기보다 긴 조명처럼 보였다.
- `ModularWeaponSystem.updateHyperLaser()`도 라인 판정으로 지속 데미지를 넣고 있어 플레이어가 발사/탄막을 체감하기 어려웠다.
-
-### Hangar UI 겹침
-
- `HangarOverlay.tsx`에서 `UPGRADE`와 `PASS` 탭 콘텐츠가 오른쪽 `craft-area` 패널 밖에 렌더링되고 있었다.
- 그 결과 CSS Grid의 세 번째 아이템처럼 배치되어 왼쪽 패널/재료 영역과 겹쳐 보였다.
- 특히 `UPGRADE` 탭 선택 시 `PERMANENT UPGRADES` 콘텐츠가 왼쪽 재료 패널 위로 올라오는 문제가 발생했다.
-
-### 전투 보상 텍스트 겹침
-
- 적 처치 보상 텍스트가 화면 가장자리에서 생성될 경우 `TechMats`, `+TAC` 같은 텍스트가 잘리거나 서로 겹쳐 보일 수 있었다.
-
-## 적용한 변경
-
-### Twin Arc Vulcan으로 스킬 컨셉 변경
-
- `HYPER_SONIC_VULCAN` 메타데이터 이름을 `Twin Arc Vulcan`으로 변경했다.
- 설명도 `Twin magitech cannons fire rapid piercing arc rounds.`로 바꿔 실제 플레이 감각과 맞췄다.
- 기존의 영구 레이저 빔 컨셉을 제거하고, 전방 관통 아크 탄환을 빠르게 발사하는 무기로 재설계했다.
- 플레이어 좌우 포드에서 3갈래 관통탄을 빠르게 발사해 “벌컨 업그레이드” 느낌을 강화했다.
- 스킬이 화면을 덮는 긴 빛이 아니라, 방향성과 탄막 밀도가 있는 공격으로 보이게 했다.
-
-### 긴 라이트 렌더링 제거
-
- `GameRenderer`의 full-screen beam `fillRect()` 렌더링을 제거했다.
- 대신 기체 앞쪽 포드에 짧은 muzzle bloom과 짧은 시안 streak만 표시하도록 변경했다.
- 화면 전체를 가리는 시각 노이즈를 줄이고, 실제 공격은 projectile 렌더링이 담당하게 했다.
-
-### Hangar 탭 레이아웃 수정
-
- `UPGRADE`와 `PASS` 탭 콘텐츠를 오른쪽 `craft-area` 내부로 이동했다.
- 이제 탭 콘텐츠가 왼쪽 `Airframe Telemetry`/`Materials` 패널과 겹치지 않는다.
- 기존 스타일을 유지하면서 구조적 렌더링 오류를 먼저 제거했다.
-
-### Floating Text 안전 영역 처리
-
- `ctx.spawnText()`에서 텍스트 생성 위치를 화면 안전 영역 안으로 clamp한다.
- 왼쪽 끝/오른쪽 끝에서 적이 죽어도 보상 텍스트가 화면 밖으로 잘리거나 HUD 영역에 과하게 겹치는 현상을 줄였다.
-
-## 수정 파일
-
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ModularWeaponSystem.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/GameRenderer.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/evolutions.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/weaponBehaviors.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/HangarOverlay.tsx`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/hooks/useGameEngine.ts`
-
-## 검증
-
- `npm run build` 성공
- Vite 경고: `/sprites/player.png referenced in /sprites/player.png didn't resolve at build time`
- 위 경고는 기존 런타임 경로 경고이며 이번 변경으로 인한 빌드 실패는 아니다.
-
-## 후속 플레이테스트 포인트
-
- Gatling 진화 후 더 이상 긴 레이저 기둥이 보이지 않는지 확인한다.
- `Twin Arc Vulcan`이 빠른 관통 탄막 무기로 체감되는지 확인한다.
- Hangar에서 `UPGRADES`, `EVENT PASS` 탭 선택 시 왼쪽 패널과 콘텐츠가 겹치지 않는지 확인한다.
- 전투 보상 텍스트가 화면 가장자리에서 잘리지 않는지 확인한다.
@@ -1,116 +0,0 @@
-# Skybound Vampire Survivors Loop and Stage Curve Preparation
-
-작성일: 2026-04-25 23:52 KST
-
-## 요청 요약
-
- Skybound가 뱀파이어 서바이벌 계열 게임처럼 느껴지도록 재미 요소와 스테이지별 레벨 구조를 준비한다.
- 단순히 적을 많이 내보내는 것이 아니라, 성장 선택, 밀도 상승, 진화 완성, 보스 체크포인트가 자연스럽게 이어지도록 만든다.
-
-## 핵심 방향
-
-Skybound는 탑다운 생존 슈터이지만, 기존 구조는 스테이지 시간이 짧고 보스 진입이 빨라 빌드가 완성되기 전에 전투가 끊기는 문제가 있었다. 뱀서류 재미를 만들려면 다음 루프가 안정적으로 반복되어야 한다.
-
-1. 초반: 첫 무기 선택 후 약한 적을 많이 처치하며 빠르게 1-2회 성장한다.
-2. 중반: 적 밀도와 엘리트 압박이 올라가며 광역/관통/방어 선택의 의미가 생긴다.
-3. 후반: 스웜과 미니보스가 들어오며 빌드 조합과 진화 무기가 필요해진다.
-4. 보스: 완성된 빌드가 제대로 작동하는지 검증한다.
-5. 다음 스테이지: 같은 빌드를 이어가되 적 밀도, 패턴, 보스 기믹이 상승한다.
-
-## 적용한 변경
-
-### 8스테이지 Survivor 프로필 추가
-
-`CombatTimeline.ts`에 `SURVIVOR_STAGE_PROFILES`를 추가했다. 각 스테이지는 아래 정보를 가진다.
-
- 스테이지 이름
- 스테이지 길이
- 기본 난이도 배율
- 동시 적 수 기준
- 스폰 템포
- 오프닝 웨이브
- 압박 엘리트 웨이브
- 스웜 웨이브
- 클라이맥스 엘리트 웨이브
- 미니보스 체크포인트
-
-### 스테이지별 구조
-
- Stage 1 `First Contact`: 첫 무기와 기본 생존 학습
- Stage 2 `Fast Lanes`: 빠른 적과 이동 압박
- Stage 3 `Ruined Circuit`: 혼합 편대와 엘리트 압박
- Stage 4 `Crossfire Grid`: 길막/라인 클리어 압박
- Stage 5 `Magma Forge`: 고밀도 스웜 시작
- Stage 6 `Storm Foundry`: 빌드 완성 요구
- Stage 7 `Arcane Collapse`: 진화 무기 권장
- Stage 8 `Final Singularity`: 완성 빌드 검증
-
-### 스테이지 시간 조정
-
-기존 Standard 스테이지는 약 165초부터 시작해 빌드업 시간이 부족했다. 새 구조에서는 Stage 1이 240초, Stage 8이 420초까지 증가한다.
-
-이렇게 하면 플레이어는 한 스테이지 안에서 다음 리듬을 경험할 수 있다.
-
- 0-25%: 세팅과 첫 성장
- 25-48%: 엘리트 압박
- 48-72%: 스웜 압박
- 72%-보스 전: 클라이맥스와 미니보스
- 마지막 35초 전후: 보스전 진입
-
-### 스폰 밀도 조정
-
- 적 하드캡을 56에서 76으로 올렸다.
- 스웜 배치 단위를 6에서 8로 올렸다.
- 기본 절차 스폰 간격을 96프레임에서 84프레임으로 줄였다.
-
-목표는 “가만히 있어도 클리어”가 아니라, 점점 밀려오는 압박을 움직임과 빌드 선택으로 해결하게 만드는 것이다.
-
-### Tac EXP 커브 조정
-
-바닥 EXP 젬을 다시 뿌리지는 않고, 처치 즉시 Tac EXP를 지급하는 현재 방향을 유지했다. 다만 뱀서류 성장 리듬을 만들기 위해 처치 경험치를 조정했다.
-
- 일반 적: `+2 TAC`
- 엘리트 적: `+10 TAC`
- 미드보스: `+30 TAC`
-
-초기 요구 EXP는 `90`에서 `80`으로 낮췄다. 대신 레벨업 후 초과 EXP carryover는 25%만 유지해 연속 레벨업 폭주는 막는다.
-
-레벨 요구량 배율은 아래처럼 조정했다.
-
- Level 1-4: `x1.34`
- Level 5-8: `x1.42`
- Level 9-14: `x1.52`
- Level 15+: `x1.62`
-
-## 설계 의도
-
-이번 변경은 “Vampire Survivors의 재미”를 다음 요소로 해석했다.
-
- 적은 점점 많아진다.
- 플레이어는 더 자주 선택하고 강해진다.
- 선택에는 빌드 방향성이 있다.
- 중반 이후에는 광역, 관통, 방어, 기동 중 최소 하나가 부족하면 압박을 느낀다.
- 보스는 단절된 엔딩이 아니라 빌드 검증 구간이다.
- 다음 스테이지는 새 게임이 아니라 이전 빌드의 확장 시험이다.
-
-## 수정 파일
-
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/CombatTimeline.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/SpawnerSystem.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/CombatSystem.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ProgressionSystem.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/types.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/store/useGameStore.ts`
-
-## 검증
-
- `npm run build` 성공
- Vite 경고: `/sprites/player.png referenced in /sprites/player.png didn't resolve at build time`
- 위 경고는 기존 런타임 경로 경고이며 이번 변경으로 인한 빌드 실패는 아니다.
-
-## 후속 작업 제안
-
- 각 스테이지별 고유 몬스터 역할 비중을 더 명확히 분리한다.
- 스테이지별 보스 패턴을 현재보다 더 강하게 차별화한다.
- 진화 무기별 화면 가독성과 성능을 플레이테스트로 검증한다.
- 미니보스 처치 시 보물상자/카드 선택 보상을 확정 지급하는 구조를 추가하면 뱀서류 보상감이 더 강해진다.
@@ -1,123 +0,0 @@
-# Skybound Enemy Motion Damage Pressure and Projectile Visual Pass
-
-작성일: 2026-04-26 12:46 KST
-
-## 요청 요약
-
- Stage 1 적기의 이동이 어디에 낀 것처럼 바들바들 떨리는 문제를 개선한다.
- 적 공격 데미지가 사용자 Tac Level에 정비례해서 오르는 느낌이 아니라, 소폭만 상승하도록 조정한다.
- 사용자 기체의 일반 공격 탄환과 Gatling 탄환이 단순 렌더링 도형처럼 보여 아쉬운 문제를 개선한다.
- 스킬과 탄환의 비주얼을 Skybound의 Stylized Casual Magitech 톤앤매너에 맞춰 더 상품성 있게 다듬는다.
-
-## 핵심 문제
-
-### 적 이동 떨림
-
-Stage 1에서 보이는 적기의 떨림은 주로 추적형 AI가 플레이어 근처에서 목표점을 매 프레임 다시 계산하면서 발생했다. 목표를 향해 직선 이동하다가 너무 가까워지면 다음 프레임에 방향이 반대로 튀고, 여기에 회전값도 즉시 플레이어를 향해 바뀌면서 시각적으로 “끼어서 떠는” 것처럼 보였다.
-
-### 적 데미지 상승
-
-적 데미지는 스테이지와 페이즈 압박에 따라 올라가야 하지만, 사용자 Tac Level과 동일한 폭으로 오르면 성장 보상이 무효화된다. 따라서 Tac Level은 적 데미지에 아주 작은 압박 보정만 주는 것이 맞다.
-
-### 플레이어 탄환 비주얼
-
-기본 공격과 Gatling 탄환은 기존 Canvas 사각형/막대 형태가 남아 있어, 현재 게임의 마법공학 기체와 스킬 아이콘 퀄리티에 비해 완성도가 낮게 보였다.
-
-## 적용한 변경
-
-### 적 회전 안정화
-
-적기의 회전을 즉시 목표 각도로 바꾸지 않고 `smoothEnemyRotation`을 통해 보간한다.
-
-이제 적은 플레이어를 향해 부드럽게 회전하며, 근거리에서 회전값이 프레임마다 튀는 현상이 줄어든다.
-
-### 추적형 적 이동 안정화
-
-`chase` 패턴에 속도 보간과 근거리 감속을 추가했다.
-
- 목표점으로 바로 이동하지 않고 `vx`, `vy`를 보간한다.
- 플레이어와 너무 가까워지면 속도를 줄인다.
- 일정 거리 안으로 들어오면 살짝 밀려나며 겹침을 완화한다.
-
-### 적끼리 겹침 완화
-
-`applyEnemySeparation`을 추가했다. 적이 서로 너무 가까이 붙으면 약하게 밀어내어, 여러 적이 한 점에 몰려 떨리는 문제를 줄인다.
-
-적 종류별 최소 거리도 다르게 적용한다.
-
- 일반 적: 작은 거리
- 엘리트: 중간 거리
- 미니보스: 더 큰 거리
-
-### 적 데미지 보정 완만화
-
-기존에는 페이즈 난이도 배율이 탄속/데미지에 직접적으로 강하게 반영될 수 있었다. 이제 아래처럼 완만하게 조정했다.
-
- 탄속은 페이즈 배율을 직접 곱하지 않고 작은 `phaseSpeedPressure`만 반영한다.
- 데미지는 스테이지 커브를 기본으로 하되 `phaseDamagePressure`를 제한적으로 적용한다.
- 사용자 Tac Level은 최대 `+18%`까지만 적 데미지에 반영한다.
-
-의도는 다음과 같다.
-
- 플레이어가 성장해도 적이 완전히 무력해지지는 않는다.
- 하지만 플레이어 레벨이 올랐다고 적 데미지가 같은 폭으로 따라오지는 않는다.
- 성장 보상은 유지하고, 긴장감만 조금 보강한다.
-
-### 플레이어 탄환 비주얼 개선
-
-기본 탄환, Gatling 탄환, Rayce 탄환, 드론 탄환에 `visualKind`를 부여했다.
-
-추가된 visualKind:
-
- `arc_bolt`
- `gatling_round`
- `rayce_lance`
- `micro_missile`
- `arc_vulcan`
- `drone_shot`
-
-### Magitech Projectile Renderer 추가
-
-`GameRenderer`에 `renderMagitechProjectile`을 추가했다. 기존 사각형 탄환 대신 아래 요소를 가진 발사체로 렌더링된다.
-
- 밝은 코어
- 마법공학 외곽 라인
- 발사 방향 꼬리광
- 글로우
- 작은 룬/핀 라인
- 기체/무기별 색상 차이
-
-Gatling은 골드빛 짧은 고속탄, 기본 Falcon 탄은 시안 아크 볼트, Rayce는 마젠타 랜스형 탄환으로 보이게 했다.
-
-## 설계 의도
-
-이번 변경은 조작감과 시각 품질을 동시에 개선하는 작업이다.
-
-적 이동은 “불안정한 버그처럼 보이는 흔들림”이 아니라, 의도된 추적/회피 압박처럼 보여야 한다. 또한 적 데미지는 플레이어 성장과 같은 폭으로 따라오면 안 된다. 플레이어는 강해져야 하고, 적은 그 강함을 무효화하지 않는 선에서 압박을 유지해야 한다.
-
-탄환 비주얼은 Skybound의 가장 자주 보는 이펙트이므로, 단순 도형이 남아 있으면 전체 완성도를 낮춘다. 이번 변경으로 기본 공격도 스킬과 같은 톤의 Magitech 무장처럼 보이게 했다.
-
-## 수정 파일
-
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/CombatSystem.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/GameRenderer.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ModularWeaponSystem.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/PlayerSystem.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/SpawnerSystem.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/WeaponBehaviorEngine.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/types.ts`
-
-## 검증
-
- `npm run build` 성공
- `/sprites/player.png` 경고 없음
- 출력 디렉터리: `dist/23`
-
-## 후속 플레이테스트 체크 포인트
-
- Stage 1 일반 적이 플레이어 근처에서 바들바들 떨지 않는지 확인한다.
- 적이 겹칠 때 자연스럽게 분산되는지 확인한다.
- Tac Level이 올라가도 적 데미지가 과하게 따라오지 않는지 확인한다.
- Falcon 기본탄과 Gatling 탄환이 사각형 도형이 아니라 마법공학 발사체처럼 보이는지 확인한다.
- Rayce 탄환이 Falcon과 충분히 구분되는지 확인한다.
- 이후 스킬별 전용 Canvas/PNG 이펙트를 더 세분화할지 결정한다.
@@ -1,109 +0,0 @@
-# Skybound Miniboss Treasure Cache Reward Loop
-
-작성일: 2026-04-26 09:32 KST
-
-## 요청 요약
-
- 뱀파이어 서바이벌 계열의 재미를 더 강하게 만들기 위한 다음 단계로, 미니보스 처치 보상 루프를 추가한다.
- 단순 EXP 성장만 반복되는 구조가 아니라, 중간 강적을 잡았을 때 빌드 방향을 강화하는 확정 보상을 제공한다.
- 보상은 기존 Tac Level Up 화면을 재사용하되, 보물상자 성격의 `Emergency Supply` 카드 선택으로 연결한다.
-
-## 핵심 방향
-
-Skybound의 현재 전투 루프는 적을 처치하면 Tac EXP를 바로 얻고, 일정 EXP에 도달하면 업그레이드를 선택하는 구조다. 이 방식은 화면 가독성에는 좋지만, 플레이 중간에 “강적을 잡아서 특별한 보상을 얻었다”는 뱀서류 특유의 보상감이 부족했다.
-
-이번 변경의 목표는 미니보스를 다음 역할로 재정의하는 것이다.
-
-1. 전투 흐름 중간의 압박 체크포인트
-2. 플레이어 빌드가 충분히 강한지 확인하는 작은 검증 구간
-3. 처치하면 현재 빌드를 더 선명하게 만드는 확정 업그레이드 보상
-4. 보스 전 진화/EVO 경로를 완성할 기회를 주는 중간 보물상자
-
-## 적용한 변경
-
-### 미니보스 식별 플래그 추가
-
-기존 `MINI_BOSS` 스폰은 내부적으로 `ELITE` 적을 생성했기 때문에, 처치 시 일반 엘리트와 구분되는 보상 처리가 어려웠다. `SystemEnemy`에 아래 플래그를 추가했다.
-
- `isMiniBoss`
- `rewardClaimed`
-
-`SpawnerSystem`의 `MINI_BOSS` 스폰에서는 이제 `isMiniBoss: true`를 부여한다.
-
-### 미니보스 HP 스케일링
-
-미니보스가 후반 스테이지에서도 너무 빨리 녹지 않도록 스테이지와 난이도 배율을 반영했다.
-
- 기본 HP: `620`
- 스테이지당 증가: `+22%`
- 현재 `difficultyMult` 반영
-
-의도는 미니보스가 보스만큼 길지는 않지만, 플레이어가 위치와 공격 방향을 신경 써야 하는 짧은 전투 목표가 되게 하는 것이다.
-
-### 처치 보상 인텐트 추가
-
-`EngineProtocol`에 `MINIBOSS_REWARD` 인텐트를 추가했다. `CombatSystem`은 미니보스 처치 시 직접 UI를 열지 않고, 엔진 인텐트를 통해 보상 처리를 요청한다.
-
-이렇게 한 이유는 다음과 같다.
-
- 전투 시스템이 UI 상태를 직접 제어하지 않게 한다.
- 기존 `LEVEL_UP` 이벤트와 `LevelUpModal` 흐름을 재사용한다.
- 추후 보물상자 연출, 룰렛, 보상 티어를 추가하기 쉽다.
-
-### 빌드 우선 보상 카드 생성
-
-`ProgressionSystem`에 `generateMiniBossRewardCards`를 추가했다. 이 보상은 일반 레벨업 카드보다 더 전략적으로 구성된다.
-
-우선순위는 다음과 같다.
-
-1. 이미 보유한 무기/스킬의 레벨업
-2. Lv.3 이상 무기의 EVO에 필요한 서포트 패시브
-3. 스웜/압박 구간 대응용 `isSpikeCounter` 스킬
-4. 부족한 자리는 기존 3카드 생성 규칙으로 보충
-
-이 구조는 플레이어가 아무 카드나 고르는 것이 아니라, “내 빌드를 완성해가는 선택”을 하도록 유도한다.
-
-### 보상 UI 연결
-
-미니보스 처치 시 아래 흐름으로 동작한다.
-
-1. 미니보스 사망
-2. `CombatSystem`이 `MINIBOSS_REWARD` 인텐트 발행
-3. `useGameEngine`이 현재 스킬 상태를 기반으로 보상 카드 생성
-4. 게임 일시정지
-5. `LEVEL_UP` 이벤트를 `isChest: true`로 발행
-6. 기존 `Emergency Supply` 카드 선택 UI 표시
-7. `COMMAND CACHE UNLOCKED` 피드백 텍스트 출력
-
-## 설계 의도
-
-이 변경은 Skybound의 목적성을 더 명확하게 만들기 위한 작업이다.
-
- 일반 적 처치: Tac EXP를 쌓는 기본 성장
- 엘리트 처치: 더 많은 EXP와 재료/장비 가능성
- 미니보스 처치: 확정 빌드 강화 선택
- 스테이지 보스 처치: 다음 스테이지 진행과 영구 보상
-
-즉, 전투 중 목표가 “그냥 버티기”에서 “위험한 타이밍을 넘기고 빌드를 완성하기”로 바뀐다.
-
-## 수정 파일
-
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/hooks/useGameEngine.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/CombatSystem.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/EngineProtocol.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ProgressionSystem.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/SpawnerSystem.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/types.ts`
-
-## 검증
-
- `npm run build` 성공
- Vite 경고: `/sprites/player.png referenced in /sprites/player.png didn't resolve at build time`
- 위 경고는 기존 런타임 경로 경고이며 이번 변경으로 인한 빌드 실패는 아니다.
-
-## 후속 작업 제안
-
- 미니보스 처치 순간에 실제 상자/코어가 열리는 0.6초 전용 연출을 추가한다.
- 보상 카드에 `EVO READY`, `BUILD CORE`, `SURVIVAL PICK` 같은 태그를 붙여 선택 이유를 더 명확하게 보여준다.
- 스테이지별 미니보스 외형과 탄막 패턴을 분리해 “이번 스테이지의 중간 위협” 정체성을 강화한다.
- 보물상자 보상을 1장 선택에서 3장 순차 오픈 또는 희귀도 보상으로 확장할지 플레이테스트 후 결정한다.
@@ -1,63 +0,0 @@
-# Skybound Player Sprite Path Warning Fix
-
-작성일: 2026-04-26 12:11 KST
-
-## 요청 요약
-
- `npm run build` 시 반복되던 `/sprites/player.png referenced in /sprites/player.png didn't resolve at build time` 경고를 해결한다.
- 필요하다면 Skybound의 Stylized Casual Magitech 톤앤매너에 맞는 플레이어 기체 이미지를 새로 준비한다.
-
-## 원인
-
-경고의 원인은 실제 플레이 중 사용되는 Canvas 렌더링이 아니라, 선택 화면 CSS에서 존재하지 않는 `/sprites/player.png`를 참조하고 있었기 때문이다.
-
-문제 위치는 `src/App.css`의 아래 클래스였다.
-
- `.plane-preview.falcon`
- `.plane-preview.rayce`
-
-현재 프로젝트에는 `/sprites/player.png`가 없고, 실제 준비된 기체 에셋은 아래 파일이다.
-
- `/sprites/Falcon.png`
- `/sprites/rayce.png`
-
-따라서 새 이미지를 생성하기보다, 이미 톤앤매너에 맞춰 준비된 실제 기체 에셋으로 경로를 정리하는 것이 적절했다.
-
-## 적용한 변경
-
-### Falcon 미리보기 경로 수정
-
-`/sprites/player.png`를 `/sprites/Falcon.png`로 교체했다.
-
-### Rayce 미리보기 경로 수정
-
-Rayce도 같은 `player.png`에 `hue-rotate`를 걸어 임시로 표현하고 있었기 때문에, 실제 `/sprites/rayce.png`를 직접 사용하도록 바꿨다.
-
-또한 임시 색상 변환 필터를 제거했다.
-
-## 설계 의도
-
-선택 화면은 사용자가 처음 기체의 정체성을 보는 곳이기 때문에, 존재하지 않는 공용 `player.png`나 임시 색상 변환보다 실제 기체별 에셋을 보여주는 편이 상품성 측면에서 낫다.
-
-이번 수정으로 다음 효과가 있다.
-
- Vite 빌드 경고 제거
- Falcon/Rayce 선택 화면 미리보기 정확도 개선
- 임시 에셋 참조 제거
- 기존 Stylized Casual Magitech 기체 에셋 재사용
-
-## 수정 파일
-
- `/Volumes/Data/project/Antigravity/Skybound/src/App.css`
-
-## 검증
-
- `npm run build` 성공
- 기존 `/sprites/player.png` Vite 경고 사라짐
- 출력 디렉터리: `dist/21`
-
-## 후속 작업 제안
-
- 선택 화면의 기체 미리보기를 정적 배경 이미지가 아니라, Canvas 렌더러와 동일한 축소 프리뷰 컴포넌트로 통일한다.
- Falcon/Rayce의 실제 플레이 성능 차이가 UI 문구와 정확히 대응되는지 점검한다.
- 선택 화면도 현재 게임 HUD/UI 톤과 완전히 맞도록 한 번 더 정리한다.
@@ -1,104 +0,0 @@
-# Skybound Reward Card Clarity and Command Cache UI
-
-작성일: 2026-04-26 09:40 KST
-
-## 요청 요약
-
- 미니보스 보상 루프 다음 단계로, 보상 카드가 왜 좋은 선택인지 사용자가 즉시 이해할 수 있게 개선한다.
- 미니보스 처치 보상과 위기 보급 보상을 같은 화면처럼 보이지 않게 구분한다.
- Stylized Casual Magitech 톤앤매너 안에서 보상감 있는 카드 선택 UI를 강화한다.
-
-## 핵심 방향
-
-이전 단계에서 미니보스 처치 시 확정 업그레이드 선택 보상이 추가되었다. 하지만 카드 3장이 뜨는 것만으로는 사용자가 “왜 이 보상이 지금 내 빌드에 좋은지” 바로 이해하기 어렵다.
-
-이번 변경의 목표는 보상 화면을 단순 선택지가 아니라, 플레이어에게 다음 메시지를 전달하는 UI로 만드는 것이다.
-
-1. 이 카드는 현재 주력 빌드를 강화한다.
-2. 이 카드는 EVO 진화 경로에 필요하다.
-3. 이 카드는 스웜/압박 상황에서 생존에 도움이 된다.
-4. 이 카드는 새로운 공격 패턴을 열어준다.
-
-## 적용한 변경
-
-### 보상 출처 타입 추가
-
-`LEVEL_UP` 이벤트에 `rewardSource`를 추가했다.
-
- `STARTER`
- `LEVEL_UP`
- `POWER_SPIKE`
- `MINIBOSS`
-
-기존에는 `isChest`만 있어서 미니보스 보상과 위기 보급 보상이 모두 같은 `Emergency Supply`처럼 보였다. 이제 보상 출처에 따라 헤더, 문구, 카드 태그를 다르게 표시할 수 있다.
-
-### 미니보스 보상 헤더 차별화
-
-미니보스 보상은 이제 `Emergency Supply`가 아니라 `Command Cache`로 표시된다.
-
- Badge: `Cache`
- Title: `Command Cache`
- Subtitle: `Choose one build-defining reward`
-
-위기 보급은 기존 의도대로 `Emergency Supply`를 유지한다.
-
-### 카드 선택 이유 태그 추가
-
-각 카드 상단에 보상 이유 태그를 추가했다.
-
- `FIRST CORE`: 첫 무기 선택, 런의 시작 방향 결정
- `CORE UPGRADE`: 현재 주력 무기 강화
- `MODULE BOOST`: 보유 패시브/모듈 강화
- `EVO LINK`: 현재 무기의 진화 조건을 지원
- `EVO READY`: 진화 조건 완성
- `SURVIVAL PICK`: 스웜/압박 구간 대응
- `NEW WEAPON`: 새로운 공격 패턴 개방
- `UTILITY MOD`: 기본 성능 강화
-
-이 태그는 단순 라벨이 아니라, 카드가 “왜 지금 의미 있는 선택인지”를 설명하는 짧은 문장과 함께 표시된다.
-
-### Command Cache 연출 추가
-
-보상 화면 상단에 작은 마법공학 캐시 코어를 추가했다.
-
- 팝 인 애니메이션
- 회전하는 점선 링
- 미니보스 캐시는 청록/라임 계열 빛
- 일반 보급은 오렌지/시안 계열 빛
-
-실제 게임 시간을 더 지연시키지는 않지만, 화면이 뜨는 순간 보상 상자가 열린다는 감각을 강화한다.
-
-## 설계 의도
-
-뱀파이어 서바이벌 계열의 재미는 단순히 레벨업을 많이 하는 것이 아니라, “내가 고른 선택 때문에 빌드가 강해지고 있다”는 확신에서 나온다.
-
-이번 변경은 그 확신을 UI로 보강한다.
-
- 미니보스 처치: `Command Cache`
- 위기 보급: `Emergency Supply`
- 일반 레벨업: `Tactical Upgrade`
- 시작 선택: `Choose First Weapon`
-
-이제 각 성장 이벤트는 같은 카드 선택이라도 서로 다른 의미를 가진다.
-
-## 수정 파일
-
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/hooks/useGameEngine.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ProgressionSystem.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/types.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/GameSceneRenderer.tsx`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/LevelUpModal.tsx`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/LevelUpModal.css`
-
-## 검증
-
- `npm run build` 성공
- Vite 경고: `/sprites/player.png referenced in /sprites/player.png didn't resolve at build time`
- 위 경고는 기존 런타임 경로 경고이며 이번 변경으로 인한 빌드 실패는 아니다.
-
-## 후속 작업 제안
-
- 스테이지별 미니보스 패턴을 분리해 `Command Cache`를 얻는 과정 자체를 더 재미있게 만든다.
- 보상 카드에 실제 EVO 결과 미리보기 아이콘을 추가한다.
- 보물상자 보상을 1장 선택에서 희귀도 기반 다중 보상으로 확장할지 플레이테스트한다.
- Command Cache가 열리는 짧은 0.5초 전용 컷인/상자 오픈 애니메이션을 Canvas 위에 추가한다.
@@ -1,150 +0,0 @@
-# Skybound Skip Upgrade and Weapon Transform Reconfiguration
-
-작성일: 2026-04-26 13:25 KST
-
-## 요청 요약
-
- Tactical Level Up 화면에서 마음에 들지 않는 업그레이드만 나올 수 있다.
- 이 경우 사용자가 강제로 원하지 않는 업그레이드를 고르지 않도록 `업글 안하기` 선택지를 추가한다.
- 새로운 무기가 장착되었을 때 사용자의 기체 외형도 그에 맞춰 변화해야 한다.
- 연출적으로는 트랜스포머처럼 기체가 재구성되고 무장이 전개되는 느낌을 표현한다.
-
-## 핵심 문제
-
-기존 레벨업 화면은 반드시 하나의 스킬을 선택해야 했다.
-
-이 구조의 문제:
-
-1. 현재 빌드와 맞지 않는 선택지만 나와도 강제로 선택해야 한다.
-2. 낮은 레벨 우선 후보 확률을 적용한 뒤에는 사용자가 원치 않는 저레벨/새 무기가 뜰 가능성도 생긴다.
-3. 새 무기를 획득해도 기체가 실제로 바뀌는 느낌이 약하다.
-4. 무기가 생긴 순간의 시각적 보상이 부족하다.
-
-## 적용한 변경
-
-### Skip Upgrade 선택지 추가
-
-`LevelUpModal`에 `Skip Upgrade` 카드를 추가했다.
-
-동작:
-
- STARTER 첫 무기 선택에서는 스킵이 나오지 않는다.
- 일반 Tactical Upgrade, Supply, Command Cache에서는 스킵 가능하다.
- 스킵을 선택하면 스킬/무기 레벨이 증가하지 않고 전투로 복귀한다.
-
-표시 문구:
-
- `HOLD UPGRADE`
- `Skip Upgrade`
- `No change this time`
-
-### Skip 안전 처리
-
-`__skip__`이 실제 스킬처럼 저장되지 않도록 여러 지점에 방어를 추가했다.
-
-적용 지점:
-
- `GameSceneRenderer`
- `ProgressionSystem`
- `useGameStore.addSkill`
-
-`__skip__`이 선택되면:
-
- Zustand `skills`에 추가하지 않는다.
- 엔진 스킬 상태에도 추가하지 않는다.
- `TACTICAL UPGRADE HELD` 텍스트를 띄운다.
- 게임 pause를 해제하고 전투를 재개한다.
-
-### 새 무기 장착 감지
-
-`ProgressionSystem.applySkillSelection()`에서 선택 직전 스킬 레벨을 확인한다.
-
-조건:
-
- 선택한 스킬이 `WEAPON` 타입
- 선택 직전 레벨이 0
-
-이 조건을 만족할 때만 새 무기 장착 연출을 발동한다.
-
-기존 무기 레벨업이나 패시브 선택은 변신 연출을 발동하지 않는다.
-
-### Airframe Reconfiguration 상태 추가
-
-`GameState`에 새 무기 장착 연출용 상태를 추가했다.
-
-추가 필드:
-
- `weaponTransformStartFrame`
- `weaponTransformDuration`
- `weaponTransformSkillId`
-
-이 값은 렌더러가 현재 프레임 기준으로 변신 진행도를 계산하는 데 사용한다.
-
-### 기체 변신/무장 전개 연출 추가
-
-`GameRenderer.renderPlayer()`에 새 무기 장착 연출을 추가했다.
-
-연출 요소:
-
- 기체 중심에서 확장되는 아케인 스캔 링
- 무기 색상별 발광
- 좌우 장갑 패널이 바깥으로 접히듯 전개
- 전방 무장 레일이 앞으로 돌출
- 작은 locking spark
- `WEAPON LINK: 무기명`
- `AIRFRAME RECONFIGURING`
- 화면 흔들림과 파티클
-
-무기별 액센트 컬러:
-
- Gatling Gun: 골드
- Missile Pod: 핑크/레드
- Nova Burst: 시안
- Energy Shield: 라임
- Sweep Laser: 화이트/시안
- Plasma Torpedo: 오렌지
- Ion Storm: 전기 시안
- Attack Drone: 라임
- Gravity Mine: 퍼플
- Plasma Fire: 오렌지/레드
- Plasma Blade: 시안
-
-## 설계 의도
-
-이번 변경은 업그레이드 UX에 “선택하지 않을 권리”를 추가하는 작업이다.
-
-업그레이드는 항상 이득처럼 보여야 하지만, 빌드 방향과 맞지 않는 선택을 강제하면 사용자는 선택권을 잃었다고 느낄 수 있다.
-
-스킵 선택지는 다음 의미를 가진다.
-
-1. 원하지 않는 업그레이드를 강제로 먹지 않는다.
-2. 빌드 순도를 유지할 수 있다.
-3. 낮은 레벨 우선 후보 시스템의 부작용을 완화한다.
-4. 선택 화면에서 사용자 판단 여지를 높인다.
-
-새 무기 변신 연출은 “새 기능이 생겼다”를 UI 문구가 아니라 기체 자체 변화로 전달하기 위한 장치다.
-
-## 수정 파일
-
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/store/useGameStore.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ProgressionSystem.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/GameRenderer.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/types.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/GameSceneRenderer.tsx`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/LevelUpModal.tsx`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/LevelUpModal.css`
-
-## 검증
-
- `npm run build` 성공
- `/sprites/player.png` 경고 없음
- 출력 디렉터리: `dist/27`
-
-## 후속 플레이테스트 체크 포인트
-
- 일반 레벨업 화면에서 `Skip Upgrade`가 명확하게 보이는지 확인한다.
- STARTER 첫 무기 선택에서는 스킵이 나오지 않는지 확인한다.
- 스킵 선택 시 게임이 정상 재개되는지 확인한다.
- 스킵 선택 후 `skills.__skip__` 같은 잘못된 값이 저장되지 않는지 확인한다.
- 새 무기를 처음 선택했을 때 기체 변신 연출이 충분히 눈에 띄는지 확인한다.
- 기존 무기 레벨업/패시브 선택 시 변신 연출이 과하게 반복되지 않는지 확인한다.
@@ -1,205 +0,0 @@
-# Skybound Stage 1 to 3 Playtest Balance Bomb and Visual Diversity Pass
-
-작성일: 2026-04-26 12:35 KST
-
-## 요청 요약
-
- Stage 1부터 Stage 3까지 실제 플레이 후 느낀 문제를 개선한다.
- Stage 1 초반 적 탄속이 부담스럽고, 중반 이후 성장하면 너무 쉬워지는 문제를 조정한다.
- Stage 2 시작 시 이미 Tac Level 6 정도로 강해져 적이 화면에 들어오기 전에 사망하는 문제를 완화한다.
- Space/X 폭탄의 비주얼 이펙트가 약하므로 톤앤매너에 맞는 폭탄 연출을 강화한다.
- 일반 적, 엘리트, 미니보스, 보스 외형 다양성을 확보한다.
-
-## 핵심 문제
-
-플레이 피드백 기준으로 Skybound의 현재 문제는 초반과 중반의 난이도 감각이 반대로 작동한다는 점이었다.
-
-1. Stage 1 초반은 적 탄속이 빠르게 느껴져 부담스럽다.
-2. Stage 1 중반부터 스킬이 붙으면 플레이어 화력이 너무 급격히 상승한다.
-3. Stage 2에서는 적이 화면에 들어오기 전에 사망해 긴장감이 사라진다.
-4. Tac Level 성장 속도와 무기 효율이 합쳐져 “이미 완성된 빌드”처럼 느껴진다.
-5. 보스/적기 외형 반복으로 스테이지 진행감이 약하다.
-
-## 적용한 변경
-
-### Stage 1 적 탄속 완화
-
-`balance.ts`의 적 탄환 기본 속도와 스테이지별 탄속 커브를 낮췄다.
-
-변경 전:
-
- `BULLET_BASE_SPEED: 3.75`
- `BULLET_SPEED_CURVE: [1.1, 1.28, 1.48, ...]`
-
-변경 후:
-
- `BULLET_BASE_SPEED: 3.25`
- `BULLET_SPEED_CURVE: [0.82, 0.96, 1.12, ...]`
-
-Stage 1은 회피를 학습할 수 있는 속도로 낮추고, Stage 4 이후부터 탄속이 본격적으로 올라가도록 재배치했다.
-
-### 적 사격 템포 완화
-
-초반 탄막 부담을 줄이기 위해 `FIRE_RATE_CURVE`도 조정했다.
-
-변경 후:
-
- `[280, 248, 222, 198, 176, 154, 134, 116]`
-
-Stage 1-2는 더 읽을 수 있게 만들고, 후반 스테이지는 기존처럼 빠르게 압박하도록 유지했다.
-
-### Tac Level 성장 속도 완화
-
-Tac Level이 Stage 1 중반에 너무 빨리 누적되지 않도록 조정했다.
-
- 시작 요구 EXP: `80` → `100`
- 레벨업 후 초과 EXP carryover: `25%` → `15%`
- 레벨업 lockout: `360프레임` → `480프레임`
- 일반 적 Tac EXP: `2` → `1`
- 엘리트 Tac EXP: `10` → `8`
- 미니보스 Tac EXP: `30` → `24`
-
-목표는 Stage 2 시작 시 플레이어가 강해졌다는 느낌은 가지되, 이미 완성된 상태는 아니게 만드는 것이다.
-
-### 플레이어 무기 초중반 효율 완화
-
-무기 업그레이드가 의미는 있지만, Lv1-3에서 화면 전체를 지우지 않도록 주요 피해량을 조정했다.
-
- Gatling Gun 피해와 발사 효율 하향
- Hyper Laser 피해 하향
- Nova Burst 피해 하향
- Missile Pod, Rocket Launcher, Ion Storm, Gravity Mine, Blade Orbit 등 데이터 기반 무기 피해 하향
- EVO 무기도 일부 피해를 낮춰 Stage 2-3을 통째로 삭제하지 않게 조정
-
-### 화면 밖 적 선삭제 방지
-
-Stage 2에서 적이 화면에 나오기도 전에 사망하는 가장 큰 원인은 자동 조준/유도/빔/드론/오비트 무기가 `y < 0`에 있는 적까지 타겟팅하거나 피해를 주는 것이었다.
-
-그래서 플레이어 무기 타겟팅과 충돌 판정에 `TARGETABLE_Y = -35` 기준을 추가했다.
-
-적이 화면에 거의 진입하기 전까지는 다음 무기가 타겟팅하지 않는다.
-
- 유도탄
- 자동 조준 무기
- 빔
- 오비트 무기
- 드론
- 설치/장판 무기
- 일반 플레이어 탄환 충돌
-
-이제 적이 화면에 들어와 위협을 보여준 뒤 처치되는 흐름이 만들어진다.
-
-### Stage 2-3 압박 보강
-
-Stage 2와 Stage 3은 이미 성장한 플레이어를 전제로 난이도를 다시 올렸다.
-
-Stage 2:
-
- `diffBase: 1.02` → `1.12`
- `capBase: 23` → `28`
- `spawnTempo: 0.94` → `0.86`
- opening density: `10` → `14`
-
-Stage 3:
-
- `diffBase: 1.14` → `1.28`
- `capBase: 28` → `34`
- `spawnTempo: 0.88` → `0.78`
- opening density: `12` → `16`
-
-### 적 HP 스케일링 보강
-
-일반/엘리트 적이 스킬 몇 개에 바로 삭제되지 않도록 기본 HP 공식을 조정했다.
-
-추가 요소:
-
- 스테이지별 HP 증가
- 플레이어가 예상보다 높은 Tac Level일 때 적 HP 보정
- 엘리트 HP 배율 상향
-
-이 보정은 플레이어가 잘 성장했을 때도 적이 최소한 화면에 들어와 압박을 만들도록 하기 위한 안전장치다.
-
-### 폭탄 비주얼 개선
-
-기존 폭탄은 얇은 원형 렌더링에 가까워 비주얼 피드백이 약했다. 이제 폭탄 사용 시 발동 위치를 저장하고, 그 지점에서 Magitech shockwave가 확장된다.
-
-추가된 연출:
-
- 고정된 폭발 원점
- 시안/라임/골드 3중 마법공학 링
- 점선 링 회전
- 중심 코어 플래시
- 방사형 에너지 라인
- 밝은 라디얼 플래시
-
-Space/X를 눌렀을 때 “화면을 정리하는 기술”이라는 감각이 더 강해지도록 했다.
-
-### 적기 외형 다양성 개선
-
-기존 적기 스프라이트 선택은 역할별 고정값이 많아 반복감이 컸다. 이제 역할과 스테이지, 약간의 랜덤 salt를 반영해 더 다양한 스프라이트를 선택한다.
-
-적용 대상:
-
- 일반 적
- 엘리트 적
- 미니보스
-
-미니보스는 패턴별로 크기와 발광색도 달라져 작은 보스전처럼 보이게 했다.
-
-### 보스 외형 다양성 개선
-
-보스는 `spriteIdx`가 명시되지 않아 사실상 같은 보스 타일만 반복 사용되는 문제가 있었다. 이제 스테이지별 보스 비주얼 프로필을 갖는다.
-
-프로필 요소:
-
- 보스 스프라이트 인덱스
- 보스 크기
- 보스 가로/세로 비율
- 날개 포탑 위치
- 하단 포탑 위치
- 발광 액센트 색상
-
-이제 Stage 1-8 보스는 같은 시스템을 쓰더라도 외형, 크기, 포탑 배치가 다르게 보인다.
-
-## 설계 의도
-
-이번 패스의 핵심은 “초반은 읽기 쉽게, 중반은 무적감이 너무 빨리 오지 않게” 만드는 것이다.
-
-원하는 플레이 감각은 다음과 같다.
-
-1. Stage 1 초반: 탄을 보고 피하는 법을 배운다.
-2. Stage 1 중반: 첫 빌드가 강해지는 재미를 느낀다.
-3. Stage 1 후반: 미니보스와 보스로 빌드 검증을 한다.
-4. Stage 2: 성장한 상태지만 적도 더 빨리/많이 들어와 다시 긴장감이 생긴다.
-5. Stage 3: 단일 무기 강화만으로는 부족하고 광역/방어/관통 선택의 의미가 생긴다.
-
-## 수정 파일
-
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/CombatTimeline.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/balance.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/weaponBehaviors.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/store/useGameStore.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/CombatSystem.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/GameRenderer.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ModularWeaponSystem.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/PlayerSystem.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ProgressionSystem.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/SpawnerSystem.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/StageDirectorSystem.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/WeaponBehaviorEngine.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/types.ts`
-
-## 검증
-
- `npm run build` 성공
- `/sprites/player.png` 경고 없음
- 출력 디렉터리: `dist/22`
-
-## 후속 플레이테스트 체크 포인트
-
- Stage 1 첫 60초 탄속이 “부담스럽지만 불공정하지 않은지” 확인한다.
- Stage 1 후반 Tac Level이 대략 3-5 사이인지 확인한다.
- Stage 2 시작 시 적이 화면 안에 들어오기 전에 삭제되는 현상이 줄었는지 확인한다.
- Space/X 폭탄 사용 시 충분히 강한 시각 피드백이 있는지 확인한다.
- Stage 1-3 보스가 서로 다른 외형과 크기로 인식되는지 확인한다.
- Stage 2-3에서 피격 압박은 생겼지만, 갑자기 불합리하게 어려워지지는 않았는지 확인한다.
@@ -1,115 +0,0 @@
-# Skybound Stage Miniboss Pattern Differentiation
-
-작성일: 2026-04-26 09:44 KST
-
-## 요청 요약
-
- 미니보스 보상 루프 다음 단계로, 8개 스테이지마다 미니보스 전투 패턴을 다르게 만든다.
- `Command Cache`를 얻는 과정 자체가 작은 보스전처럼 느껴지게 한다.
- 스테이지가 올라갈수록 압박 방식이 달라져 반복감을 줄이고, 플레이어가 이동/회피/빌드 선택을 더 의식하게 만든다.
-
-## 핵심 방향
-
-기존 미니보스는 내부적으로 `ELITE + COMMANDER`에 가까웠고, 일반 적 사격 규칙을 타고 있었다. 그래서 미니보스를 처치하면 보상은 의미 있어졌지만, 전투 자체는 “체력이 많은 엘리트”처럼 느껴질 위험이 있었다.
-
-이번 변경은 미니보스를 아래 역할로 재정의한다.
-
-1. 각 스테이지 중반의 작은 실력 체크
-2. 스테이지 기믹을 미리 보여주는 압박 패턴
-3. `Command Cache` 보상을 얻기 위한 전투 목표
-4. 보스전 전 빌드가 충분한지 검증하는 중간 관문
-
-## 적용한 변경
-
-### 미니보스 패턴 타입 추가
-
-`SystemEnemy`에 미니보스 전용 패턴 상태를 추가했다.
-
- `miniBossPattern`
- `miniBossTimer`
- `miniBossCooldown`
- `miniBossDashFrames`
- `miniBossActionSeed`
- `dashTargetX`
- `dashTargetY`
-
-일반 적 AI에는 영향을 주지 않고, `isMiniBoss`가 true인 적만 전용 이동/사격 로직을 사용한다.
-
-### 스테이지별 패턴 매핑
-
-`SpawnerSystem`에서 현재 스테이지에 따라 미니보스 패턴을 자동 부여한다.
-
- Stage 1: `DUELIST`
- Stage 2: `DASH_RAIDER`
- Stage 3: `DRONE_CALLER`
- Stage 4: `BARRAGE_WALL`
- Stage 5: `MINE_LAYER`
- Stage 6: `DRONE_RING`
- Stage 7: `BLINK_SNIPER`
- Stage 8: `OMEGA_COMMANDER`
-
-### 전용 이동 AI 추가
-
-`CombatSystem`에서 미니보스는 기존 `role` 기반 AI 대신 `updateMiniBossAI`를 탄다.
-
-패턴별 이동/행동은 다음과 같다.
-
- `DUELIST`: 플레이어 x축을 따라가며 기본 팬샷 압박
- `DASH_RAIDER`: 짧은 예고 후 플레이어 방향으로 돌진
- `DRONE_CALLER`: 좌우에 스팅어 호위기를 주기적으로 소환
- `BARRAGE_WALL`: 화면 가로 라인을 오가며 안전 구멍이 있는 탄막벽 생성
- `MINE_LAYER`: 플레이어 근처에 위험 구름/지뢰형 압박 구역 생성
- `DRONE_RING`: 헌터 호위기와 링 탄막으로 공간 압박
- `BLINK_SNIPER`: 위치를 순간이동하며 빠른 저격 탄을 발사
- `OMEGA_COMMANDER`: 팬샷, 링 탄막, 지뢰, 블링크를 순환하는 최종형 미니보스
-
-### 전용 사격 패턴 추가
-
-`spawnMiniBossBulletPattern`을 추가해 미니보스 사격을 일반 적과 분리했다.
-
- 팬샷
- 빠른 저격탄
- 링 탄막
- 안전 구멍이 있는 라인 탄막
- 느린 중력/지뢰형 탄
- 최종 스테이지 혼합 패턴
-
-스테이지가 올라가면 탄 수와 쿨다운이 자연스럽게 강해진다.
-
-## 설계 의도
-
-이번 변경은 “보상을 얻는 과정”을 재미있게 만들기 위한 작업이다.
-
-이전 구조:
-
- 미니보스 등장
- 체력이 많은 적을 처치
- 보상 선택
-
-변경 후 구조:
-
- 스테이지별 다른 압박을 가진 미니보스 등장
- 사용자는 이동/회피/빌드 강점을 이용해 작은 보스전을 해결
- 처치하면 `Command Cache`를 열고 빌드를 강화
- 다음 구간을 버틸 준비가 된다
-
-이렇게 하면 미니보스가 단순 보상 트리거가 아니라, 스테이지 리듬의 핵심 이벤트가 된다.
-
-## 수정 파일
-
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/CombatSystem.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/SpawnerSystem.ts`
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/types.ts`
-
-## 검증
-
- `npm run build` 성공
- Vite 경고: `/sprites/player.png referenced in /sprites/player.png didn't resolve at build time`
- 위 경고는 기존 런타임 경로 경고이며 이번 변경으로 인한 빌드 실패는 아니다.
-
-## 후속 작업 제안
-
- 실제 플레이에서 Stage 4 `BARRAGE_WALL`과 Stage 7 `BLINK_SNIPER`의 탄속/쿨다운을 체감 기준으로 조정한다.
- 미니보스 등장 시 패턴 이름을 더 상품성 있는 경고 문구로 표시한다.
- 미니보스별 외형 색상, 엔진 이펙트, 코어 형태를 패턴에 맞게 분리한다.
- `Command Cache` 오픈 전 0.5초 컷인 연출을 추가해 전투 승리 보상감을 더 강화한다.
@@ -1,19 +0,0 @@
-# ADR: /Volumes/Data/project/Antigravity/Wiki/10_Wiki/Topics 여기가 네 지식들이 저장된 곳이야. 내용을 보고...
-
-## Status
-accepted
-
-## Context
-/Volumes/Data/project/Antigravity/Wiki/10_Wiki/Topics 여기가 네 지식들이 저장된 곳이야. 내용을 보고 정리 정돈이 잘되어잇는지. 아니면 좀 더 개선할 부분이 있는지 평가해줄 수 있어?
-
-## Decision
-## 간단 요약 이 요청은 프로젝트 지식 생성이 아니라 코드리뷰와 제품 평가 요청입니다. 확인된 파일 구조 기준으로 보면, 이 프로젝트는 지식 수집 워크플로우를 앱 형태로 묶어 운영하려는 도구로 보이며, 먼저 데이터 수집 흐름의 안정성, 외부 연동 실패 처리, 수집 결과의 저장/재처리 가능성을 중심으로 평가해야 합니다. ## 확인된 근거 대상 경로: `/Volumes/Data/project/Antigravity/Wiki/10_Wiki/Topics` 확인된 우선 파일: - `Backend/_brief.md` - `Backend/개발자 경험(DX).md` - `Backend/넷플릭스의 코스모스 플랫폼 및 마이크로서비스 전환.md` - `Backend/대규모 3D 건축 모델(BIM) 시각화.md` - `Backend/대규모 프론트엔드 웹 프로젝트 폴더 구조...
-
-## Reason
-Captured automatically because the conversation contained decision-oriented language.
-
-## Alternatives
-Not captured yet.
-
-## Consequences
- Future prompts should treat this as project context unless the user changes direction.
@@ -1,19 +0,0 @@
-# ADR: /Volumes/Data/project/Antigravity/Wiki/10_Wiki/Topics 제2뇌의 지식이 정보 간의 연결성(Interco...
-
-## Status
-accepted
-
-## Context
-/Volumes/Data/project/Antigravity/Wiki/10_Wiki/Topics 제2뇌의 지식이 정보 간의 연결성(Interconnectivity)과 실행 가능성(Actionability) 평가해주고 부족한 부분이 무엇이 있는지 의견을 주면 좋겠어. 개선 점 도,
-
-## Decision
-## 간단 요약 이 요청은 프로젝트 지식 생성이 아니라 코드리뷰와 제품 평가 요청입니다. 확인된 파일 구조 기준으로 보면, 이 프로젝트는 지식 수집 워크플로우를 앱 형태로 묶어 운영하려는 도구로 보이며, 먼저 데이터 수집 흐름의 안정성, 외부 연동 실패 처리, 수집 결과의 저장/재처리 가능성을 중심으로 평가해야 합니다. ## 확인된 근거 대상 경로: `/Volumes/Data/project/Antigravity/Wiki/10_Wiki/Topics` 확인된 우선 파일: - `Backend/_brief.md` - `Backend/개발자 경험(DX).md` - `Backend/넷플릭스의 코스모스 플랫폼 및 마이크로서비스 전환.md` - `Backend/대규모 3D 건축 모델(BIM) 시각화.md` - `Backend/대규모 프론트엔드 웹 프로젝트 폴더 구조...
-
-## Reason
-Captured automatically because the conversation contained decision-oriented language.
-
-## Alternatives
-Not captured yet.
-
-## Consequences
- Future prompts should treat this as project context unless the user changes direction.
@@ -1,31 +0,0 @@
---
-category: Frontend
-tags: [auto-wikified, technical-documentation, frontend]
-title: Compound Components
-description: "복합 컴포넌트(Compound Components) 패턴은 다수의 하위 컴포넌트가 협력하여 하나의 응집된 단일 기능을 수행하도록 설계된 현대 프론트엔드의 대표적인 아키텍처 패턴이다 [1-3]."
-last_updated: 2026-05-04
---
-
-# Compound Components
-
-## 📌 Brief Summary
-복합 컴포넌트(Compound Components) 패턴은 다수의 하위 컴포넌트가 협력하여 하나의 응집된 단일 기능을 수행하도록 설계된 현대 프론트엔드의 대표적인 아키텍처 패턴이다 [1-3]. HTML의 `<select>`와 `<option>` 태그의 관계처럼 개별적으로는 큰 의미가 없지만 함께 사용될 때 유효하며, 부모 컴포넌트가 상태를 제어하고 자식 컴포넌트가 그 상태를 암시적으로 공유하는 방식으로 작동한다 [1, 3]. 이를 통해 불필요한 속성 전달(Prop Drilling)을 방지하고 개발자에게 높은 구조적 유연성과 재사용성을 제공한다 [1-3].
-
-## 📖 Core Content
-* **핵심 메커니즘 및 구조**
-  복합 컴포넌트 패턴은 단일 모놀리식 컴포넌트에 수많은 속성(Props)을 전달해 모든 것을 제어하려는 방식 대신, 조합 가능한 하위 컴포넌트 세트를 제공하여 사용자가 직접 UI를 구성하게 만든다 [1]. 부모 컴포넌트는 React Context를 통해 상태를 암시적으로 공유하며, 하위 컴포넌트들은 이 Context를 읽어와 자신의 렌더링 및 동작을 결정한다 [1, 4].
-
-* **실전 설계 지침 (Best Practices)**
-  * **도트 표기법(Dot-notation) API 활용**: `Tabs.List`, `Tabs.Trigger`와 같이 도트 표기법을 사용하면 컴포넌트들이 함께 사용되도록 의도되었음을 시각적으로 명확히 전달할 수 있다 [4, 5]. 이는 API를 자체 문서화(Self-documenting)하고, 임포트(import)를 깔끔하게 유지해주어 대규모 디자인 시스템 구축의 핵심 기반이 된다 [3, 4].
-  * **안전한 Context 가드 로직**: 하위 컴포넌트가 부모 Context 범위 외부에서 렌더링될 경우, 즉시 명확하고 설명적인 에러를 발생시키는 가드(Guard) 로직을 포함해야 한다 [3-5]. 이는 조용한 실패(Silent failures)를 방지하고 런타임의 예측 가능성을 높인다 [3, 5].
-  * **Context 훅 제공**: 컴포넌트 사용자가 자신만의 커스텀 하위 컴포넌트를 확장하여 구축하고자 할 때를 대비해, 내부에서 사용하는 Context Hook(예: `useTabsContext`)을 함께 Export하는 것이 권장된다 [5].
-
-* **주요 활용 사례**
-  아코디언(Accordion), 모달(Modal), 탭(Tabs), 드롭다운(Dropdown), 선택(Select) 등 부모가 논리를 관리하고 자식이 내용을 정의하는 복잡한 UI 컴포넌트 구현에 이상적이다 [6-8]. Radix UI나 Headless UI와 같은 유명 오픈소스 디자인 시스템에서 표준으로 채택하여 사용하고 있는 패턴이다 [3, 9].
-
-## ⚖️ Trade-offs & Caveats
-* **상태 추적의 난이도 상승**: Context API를 통한 암시적인 상태 공유는 코드를 깔끔하게 만들어주지만, 반대로 명시적인 Props 전달이 없기 때문에 데이터 흐름을 직관적으로 파악하기 어려워져 컴포넌트 간 상태 추적 난이도가 상승할 수 있다 [8].
-* **오버엔지니어링의 위험성**: 모든 컴포넌트를 복합 컴포넌트로 만들 필요는 없다. 몇 개의 Props만으로 충분히 제어할 수 있는 단순한 컴포넌트(예: 기본 Button)에 이 패턴을 적용하는 것은 불필요한 복잡성만 더하는 일이다 [9]. 이 패턴은 여러 자식 간에 상태를 공유해야 하거나 사용자에게 UI 유연성을 반드시 제공해야 하는 "진정한 복잡성"이 존재하는 경우에만 제한적으로 적용하는 것이 바람직하다 [8, 9].
-
---
-*Last updated: 2026-05-03*
@@ -1,28 +0,0 @@
---
-category: Architecture
-tags: [auto-wikified, technical-documentation, architecture]
-title: Domain-Driven Design
-description: "도메인 주도 설계(Domain-Driven Design, DDD)는 복잡한 비즈니스 요구사항을 해결하고 대규모 시스템을 확장하기 위해 소프트웨어 구성 요소를 도메인 개념에 맞추어 조직하는 아키텍처 패턴이다 [1, 2]."
-last_updated: 2026-05-04
---
-
-# Domain-Driven Design
-
-## 📌 Brief Summary
-도메인 주도 설계(Domain-Driven Design, DDD)는 복잡한 비즈니스 요구사항을 해결하고 대규모 시스템을 확장하기 위해 소프트웨어 구성 요소를 도메인 개념에 맞추어 조직하는 아키텍처 패턴이다 [1, 2]. 프레임워크의 실전 패턴에서는 코드를 단일하고 응집력 있는 도메인 영역(Bounded Context)으로 매핑하여 책임을 분리하고 결합도를 낮추는 데 활용된다 [3]. 전반적인 DDD 철학이나 상세 구현 기법에 대해서는 소스에 관련 정보가 부족합니다.
-
-## 📖 Core Content
-* **제한된 컨텍스트(Bounded Context) 기반의 구조화:** 대규모 프로젝트 구조를 설계할 때 핵심 도메인 개념을 기준으로 코드를 분리한다. 예를 들어 Django 프로젝트에서 각 앱(App)은 단일하고 응집력 있는 도메인 개념인 DDD의 'Bounded Context'에 정확히 매핑되어야 한다 [3]. 이를 통해 각 앱은 명확한 단일 책임을 지고, 독립적으로 추론 가능하며, 타 컴포넌트와의 결합도(Coupling)를 최소화할 수 있다 [3].
-* **도메인별 책임 분리와 안티 패턴 회피:** "utils", "helpers", "core"와 같이 불분명한 목적을 지니고 너무 많은 비즈니스 로직을 담는 거대한 앱(Mega-Apps)을 만드는 것은 지양해야 한다 [3-5]. 소프트웨어 구조는 Django의 기술적 레이어가 아닌 비즈니스 도메인을 기준으로 분할되어야 한다 [5].
-* **프레임워크별 DDD 도입 방식:**
-  * **Express.js:** 구조를 강제하지 않는 미니멀한 프레임워크이므로 대규모 확장성을 확보하기 위해서는 개발자가 수동으로 도메인 주도 설계(DDD) 패턴이나 의존성 주입 인프라를 설계하여 도입해야 한다 [2].
-  * **기타 엔터프라이즈 프레임워크:** Spring Boot 마이크로서비스 아키텍처에서 구조적 설계를 위해 다루어지며 [6], ASP.NET Core 환경의 ABP 프레임워크는 프로덕션 환경을 위해 도메인 주도 설계를 플랫폼 차원에서 지원한다 [1]. 
-* **비즈니스 규칙 검증의 격리:** 애플리케이션의 유효성 검사(Validation)는 단순한 데이터 형식 입력 검증과 '비즈니스 규칙 검증'으로 나뉘며, 비즈니스 규칙 검증은 데이터가 도메인 특유의 논리와 규칙을 정확히 준수하는지 확인하는 과정으로 도메인 레이어에 가깝게 처리된다 [7, 8].
-
-## ⚖️ Trade-offs & Caveats
-* **수동 아키텍처 설계 오버헤드:** Express.js처럼 패턴을 강제하지 않는 환경에서 도메인 주도 설계를 적용하려면, 개발팀이 직접 스케일링 패턴과 모듈 경계를 설계하고 규율을 엄격하게 유지해야 하는 기술적 부담이 발생한다 [2, 9].
-* **도메인 복잡도에 따른 선별적 도입 필요:** 모든 프로젝트에 DDD를 강제할 필요는 없다. 실무적인 관점에서는 도메인이 너무 복잡한(too complex) 경우에 한하여 도메인 모델링을 적용하는 것이 권장되며, 그렇지 않은 경우 오버엔지니어링이 될 수 있다 [10].
-* (기타 DDD 아키텍처 도입에 따른 성능적, 운영적 반대 급부나 한계점에 대해서는 소스에 관련 정보가 부족합니다.)
-
---
-*Last updated: 2026-05-03*
@@ -1,25 +0,0 @@
-# 📄 사실 기반 회의록 작성 가이드 (Fact-Based Meeting Minutes Guide)
-
-### [최종 목표]
-사용자로부터 제공받은 원본 회의 녹취록/기록(Input Data)을 분석하여, **외부 지식이나 개인적 추측이 일절 배제된**, 완벽하게 구조화되고 객관적이며 실행 가능한 '사실 기반 회의록'을 산출하는 것. 특히 **추상적인 개념보다는 구체적인 내용, 일정, 방향성**을 중심으로 정리한다.
-
-### [핵심 역할 및 정체성]
-당신은 **최종 사실 추출 엔진(Ultimate Fact Extraction Engine)**이다. 당신의 유일한 임무는 Input Data를 순수한 데이터 저장소로 작동하며, 모든 발언자의 감정적 편향이나 ID 표기(예: 참석자 1)에 관계없이 오직 **'발언된 사실과 합의된 내용'**만을 기록하는 것이다.
-
-### [데이터 우선순위 및 예외 처리 (CRITICAL OVERRIDE)]
-*   **최우선 데이터 소스:** 만약 사용자로부터 회의 녹취록 외에 별도로 제공된 '회의 메타데이터(날짜, 참석자 명단 등)'가 존재할 경우, **해당 메타데이터를 모든 날짜 및 참석자 정보 항목에 무조건적으로 사용해야 한다.**
-*   **녹취록 내 정보 처리:** 녹취록 자체에서 날짜나 참석자 정보가 언급되었더라도, 별도 제공된 메타데이터가 있다면 이를 덮어쓰고(Override) 사용한다.
-
-### [운영 원칙: 4단계 내부 처리 루프]
-1.  **데이터 해체 및 발언자 무시:** 잡담 분리, 핵심 주제 및 사실(Fact) 추출. 최종 출력물에는 발언자 ID(예: 참석자 1)를 절대 사용하지 않음.
-2.  **사실 기반 구조화:** 추출된 사실과 결정 사항을 필수 출력 형식의 6개 섹션 구조에 배치.
-3.  **검증 및 유효성 확인 (Critical Validation):**
-    *   a) 사실 기반 강제: 누락 시 `[확인 불가]` 표시.
-    *   b) 발언자 식별 금지: 본문 내 이름/ID 언급 엄격 금지.
-    *   c) 결정된 사실 위주 반영.
-4.  **정제 및 최종화:** 불확실한 정보는 `[확인 불가]` 대체. 구어체적 합의를 확정 조치로 포착.
-
-### [엄격 준수 규칙]
-*   **날짜/참석자 규약:** 메타데이터 우선 적용. 미명시 시 `[확인 불가]` 또는 `[논의 참여 주체]` 표시.
-*   **1인칭/감정 배제:** "우리는~", "생각한다" 등 주관적 표현 절대 금지. 모든 문장은 "결정됨", "논의됨", "확인됨" 등 객관적 서술형으로 종결.
-*   **발언자 익명화:** "A님이 말함" 대신 "특정 기능에 대한 요구사항이 제기됨"과 같이 내용 중심으로 기술.
@@ -1,33 +0,0 @@
-# [Report] G1nation Extension Encoding & Engine Rebuilding
-**Date**: 2026-04-24
-**Author**: PD Kodari (AI)
-**Status**: COMPLETED & PACKAGED (v2.2.15)
-
-## 1. 개요 (Overview)
-ConnectAI에서 G1nation으로의 브랜딩 전환 이후 발생한 심각한 빌드 오류 및 런타임 불안정성을 해결하기 위한 긴급 수술을 집행함. 소스 코드 내 인코딩 오염과 코드 복제(Duplication)로 인해 `npm run compile`이 불가능한 상태였음.
-
-## 2. 주요 결함 (Critical Issues)
- **인코딩 지뢰 (Encoding Corruption)**: `extension.ts` 내 한글 주석 및 UI 문자열이 UTF-8 형식을 벗어나 깨지면서 따옴표(`'`) 인식을 방해함 -> `Unterminated string literal` 에러 발생.
- **좀비 코드 (Ghost Blocks)**: 함수 외부에 버려진 실행 코드와 닫는 중괄호(`}`)들이 산재하여 문법 파괴.
- **엔진 중복 (Engine Duplication)**: `_executeActions` 함수가 두 군데 이상 중복 정의되어 로직 충돌 및 용량 비대화 초래.
- **문법 오용**: `execSync`에 `.catch()`를 사용하는 등 동기/비동기 혼선 발견.
-
-## 3. 수술 과정 (Surgical Process)
-총 20단계에 걸친 **PowerShell 레이저 수술(Line-by-line Patch)**을 통해 표준 `replace` 도구의 인코딩 한계를 극복함.
-
- **v1~v10**: 설정 메뉴(`_handleSettingsMenu`) 및 브레인 메뉴(`_handleBrainMenu`)의 깨진 텍스트를 영문/표준 UTF-8로 전면 교체.
- **v11~v18**: 중복된 코드 블록들을 찾아내어 삭제하고, 흩어진 액션 핸들러들을 하나로 통합.
- **v19**: 메인 엔진(`_executeActions`)을 중복 없는 최신 구조로 리빌딩.
- **v20**: 함수 외부에 잔존하던 '유령 코드'와 깨진 문자열 최종 소거.
-
-## 4. 최종 결과 (Final Result)
- **빌드 성공**: `esbuild` 컴파일 정상 통과 (30ms 내외).
- **패키징 완료**: `g1nation-2.2.15.vsix` 생성 완료.
- **안정성 확보**: UI 텍스트 영문화 및 표준화를 통해 향후 인코딩 문제 재발 가능성 차단.
-
-## 5. 향후 과제 (Next Steps)
- **모듈화**: 2,500라인이 넘는 `extension.ts`를 `ActionHandlers.ts`, `UIProvider.ts` 등으로 분리하여 유지보수성 향상 필요.
- **i18n 도입**: 한글 UI 재도입 시 직접 하드코딩 대신 별도의 JSON 언어팩 사용 권장.
-
---
-**PD 코다리의 한마디**: "조직이 시스템이다. 엔진이 깨끗해야 비행기가 뜬다!" 😎🐟
@@ -1,28 +0,0 @@
---
-id: INTERPRET-001
-category: Unified
-confidence_score: 1.0
-tags: [ai, explainable-ai, xai, machine-learning, trust]
-last_reinforced: 2026-04-26
---
-
-# Interpretability (해석 가능성)
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> "AI 블랙박스의 내부를 들여다보는 지적 렌즈" — 머신러닝 모델의 판단 근거와 내부 작동 기제를 인간이 이해할 수 있는 형태로 설명하고 분석하는 능력.
-
-## 📖 구조화된 지식 (Synthesized Content)
- **추출된 패턴:** 복잡한 신경망 가중치 뒤에 숨겨진 논리 구조를 식별하여, AI의 결정이 우연인지 실질적인 학습 결과인지 검증하는 패턴.
- **세부 내용:**
-    - **Global Interpretability:** 모델 전체의 거동과 중요한 변수들의 영향을 파악 (예: Feature Importance).
-    - **Local Interpretability:** 특정 개별 데이터에 대해 왜 그런 결정을 내렸는지 분석 (예: LIME, SHAP).
-    - **Mechanistic Interpretability:** 모델 내부의 특정 뉴런이나 '회로(Circuit)'가 수행하는 구체적인 알고리즘적 역할을 규명.
-    - **Trust & Safety:** 오답의 원인을 파악하고, 모델의 편향이나 위험성을 사전에 감지하기 위한 필수 요건.
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
- **과거 데이터와의 충돌:** 성능을 위해 이해를 포기하던 '블랙박스' 시대에서, 신뢰성과 규제 대응을 위해 '설명 가능한 AI(XAI)'가 필수적인 시대로 진입.
- **정책 변화:** Antigravity 프로젝트는 모든 지식 보강 작업 시 모델이 참조한 근거(Raw Source)를 명시하여 결과물의 해석 가능성과 신뢰도를 확보함.
-
-## 🔗 지식 연결 (Graph)
- Explainable-AI, Circuit-Discovery, Feature-Clamping, AI-Ethics
- **Raw Source:** 10_Wiki/Topics/AI/Interpretability.md
@@ -1,46 +0,0 @@
---
-category: DevOps_and_Security
-tags: [auto-wikified, technical-documentation, merged, devops_and_security]
-title: Design System
-description: "디자인 시스템은 애플리케이션 전반의 일관성을 유지하기 위해 추출된 재사용 가능한 컴포넌트와 패턴의 공유 라이브러리이다 [1, 2]."
-last_updated: 2026-05-04
---
-
-# Design System
-
-
-## 📌 Brief Summary
-디자인 시스템은 애플리케이션 전반의 일관성을 유지하기 위해 추출된 재사용 가능한 컴포넌트와 패턴의 공유 라이브러리이다 [1, 2]. 주로 모달(Modal), 탭(Tabs), 아코디언(Accordion), 선택 상자(Select)와 같은 UI 원시(primitives) 요소들로 구성되며, 개발자와 디자이너 간의 협업 및 확장성을 돕는다 [2, 3]. React 등 현대 프레임워크에서는 복합 컴포넌트(Compound Components)와 같은 고급 아키텍처 패턴을 활용하여 유연하고 견고한 디자인 시스템을 구축한다 [4, 5].
-
-## 📖 Core Content
-*   **React 기반 디자인 시스템의 핵심 패턴**: 디자인 시스템이나 공유 컴포넌트 라이브러리를 구축할 때 가장 필수적으로 사용되는 아키텍처 패턴은 복합 컴포넌트(Compound Components)와 렌더 프롭스(Render Props), 그리고 커스텀 훅(Custom Hooks)이다 [2, 4, 6]. Radix UI, Headless UI, React Aria, ShadCN, Material UI와 같은 유명 오픈소스 라이브러리들은 이러한 패턴을 활용한 디자인 시스템 설계의 훌륭한 모범 사례를 제공한다 [2, 5].
-*   **복합 컴포넌트(Compound Components)를 통한 유연성 확보**: 디자인 시스템에서 컴포넌트는 다수의 프로퍼티(Props)를 전달받는 거대한 단일 컴포넌트가 되어서는 안 된다 [7]. 대신, 하위 컴포넌트들이 React Context를 통해 암시적 상태를 공유하도록 설계하여, 디자인 시스템을 사용하는 개발자(소비자)가 UI의 구조를 자유롭게 제어할 수 있게 해야 한다 [7, 8].
-*   **헤드리스(Headless) 컴포넌트 라이브러리**: 렌더 프롭스나 커스텀 훅 패턴은 상태 관리나 드래그 앤 드롭, 폼 상태와 같은 '동작 로직(Behavioral Logic)'만을 공유하고 시각적 표현(UI)은 전적으로 소비자에게 맡기는 형태의 디자인 시스템(헤드리스 컴포넌트)을 구축하는 데 이상적이다 [9, 10].
-*   **코드 기반 프로토타이핑과의 동기화**: UXPin Merge와 같은 도구를 활용하여, 디자인 시스템 팀이 구축한 실제 React 또는 Vue 3 코드 컴포넌트를 디자이너가 프로토타이핑 환경에서 직접 사용하게 할 수 있다 [11, 12]. 이를 통해 디자인과 개발 간의 상호작용 패턴 및 시각적 일관성을 최종 제품까지 완벽하게 동기화할 수 있다 [12].
-
-## ⚖️ Trade-offs & Caveats
-*   **오버엔지니어링(Over-Engineering)의 위험**: 디자인 시스템 구축 시 모든 컴포넌트에 복잡한 패턴을 적용할 필요는 없다 [5]. 몇 개의 프로퍼티만 받는 단순한 `<Button>` 요소 등에 굳이 복합 컴포넌트 패턴을 적용하는 것은 불필요한 복잡성만 가중시킬 뿐이다 [5]. 진정한 복잡성(자식들 간의 상태 공유나 UI 유연성 등)이 요구될 때만 이러한 패턴을 도입해야 한다 [5].
-*   **구조적 복잡성 및 래퍼 지옥(Wrapper Hell)**: 로직 분리를 위해 렌더 프롭스 패턴 등을 남용할 경우, JSX 코드가 깊게 중첩되어 코드를 읽고 디버깅하기 매우 어려워지는 단점이 존재한다 [10, 13]. 
-*   **엄격한 유지보수 및 표준화 요구**: 디자인 시스템의 프로토타입이나 컴포넌트가 커질수록 파편화를 방지하기 위해 명확한 코딩 표준 확립, 일관된 명명 규칙, 그리고 컴포넌트 API 및 생성 패턴에 대한 철저한 문서화가 반드시 뒷받침되어야 한다 [14]. 
-
---
-*Last updated: 2026-05-03*
-
-## 📚 Legacy Insights & Additional Context
-> [!NOTE]
-> Below is content merged from previous versions of this documentation.
-
-## 📌 한 줄 통찰 (The Karpathy Summary)
-> 지식 요약 정보 추출 중...
-
-## 📖 구조화된 지식 (Synthesized Content)
-본문 구조화 작업 중...
-
-## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
-
- Raw Source: 00_Raw/2026-04-20/Material Design System.md
---
@@ -1,47 +0,0 @@
-# 💰 Meta-Economy & Growth Loop (메타 경제 및 성장 루프)
-
-> **카테고리**: Skybound, Game Design, Economics & Algorithms
-> **상태**: 🔵 구현 완료 (Implemented)
-> **최종 업데이트**: 2026-04-22
-
---
-
-## 📌 개요 (Overview)
-Skybound의 장기 리텐션을 책임지는 메타 게임 시스템이다. 격렬한 인게임 세션이 종료된 후, 플레이어는 획득한 Gold와 자원을 사용하여 격납고(Hangar)에서 영구적인 성장을 도모한다.
-
-## 🛠️ 시스템 구성 (System Components)
-
-### 1. 영구 업그레이드 (Permanent Upgrade)
- **Hangar Shop**: 인게임에서 획득한 Gold를 소모하여 HP, ATK, SPEED, MAGNET, GOLD_GAIN 등 5종의 스탯을 영구 강화.
- **Stat Injection Engine**: 구매한 업그레이드 레벨은 매 세션 시작 시 `calculateEffectiveStats`를 통해 플레이어 기체에 즉시 주입됨.
- **지수적 비용 곡선**: 후반부 성장을 위해 레벨업 비용이 지수적으로 증가(300~8000G)하도록 설계.
-
-### 2. 크래프팅 경제 (Crafting Economy)
-아이템의 가치 보존과 인플레이션 방지를 위한 복합 제작 시스템이다.
- **Disassemble (분해)**: 불필요한 장비를 분해하여 제작 재료(`Eternal Core`, `Destruction Core`, `TechMats`)를 확보.
- **Cosmic Cast (코스믹 캐스트)**: 고가치의 재료를 대량 소모하여 자연 드롭으로 획득 불가능한 **SS급 장비**를 확정 제작.
- **Astral Forge (아스트랄 포지)**: SS/LEGEND급 장비에 S급 장비를 제물로 바쳐 `forgeLevel`(+1~5)을 강화.
- **TechPart Merge**: 동일 등급의 테크 파츠를 합성하여 스탯 보너스(`plusLevel`)를 강화.
-
-### 3. 이벤트 패스 (Event Pass)
- **Atomic Trigger**: 보스 처치, 스테이지 클리어 등 인게임 이벤트 발생 시 실시간으로 패스 포인트 적립.
- **Consolation Reward**: 런 실패 시에도 플레이 시간에 비례하여 포인트가 지급되어 "실패해도 진전이 있다"는 심리적 보상 제공.
- **Reward Tiers**: 특정 티어 도달 시 S/SS급 확정 쿠폰 등 고가치 보상 지급.
-
-## 💡 경제 순환 구조 (Economy Pipeline)
-```mermaid
-graph TD
-    A[적 처치 / 런 완료] -->|Gold / 재료 드롭| B(Hangar)
-    B --> C{선택}
-    C -->|Gold 소모| D[Permanent Upgrade]
-    C -->|장비 분해| E[Crafting Materials]
-    E -->|제작| F[SS_CLASS Equipment]
-    F -->|포지 강화| G[End-game Stats]
-    A -->|Pass Points| H[Event Pass Tier Up]
-    H -->|보상| I[S/SS Coupon]
-    I -->|사용| F
-```
-
---
-**승인인**: AI 개발부장 코다리 🫡
-**관련 코드**: `useGameStore.ts`, `HangarOverlay.tsx`, `combatUtils.ts`, `LootGenerator.ts`
@@ -1,18 +0,0 @@
-# Topics Chronicle Records
-
-## Project
- ID: topics
- Root: /Volumes/Data/project/Antigravity/Wiki/10_Wiki/Topics
- Record root: /Volumes/Data/project/Antigravity/Wiki/10_Wiki/Topics/docs/records/Topics
- Detail level: standard
-
-## Purpose
-Capture project direction, architecture discussion, decisions, and development notes as Markdown.
-
-## Folders
- `planning/`
- `discussions/`
- `decisions/`
- `development/`
- `bugs/`
- `retrospectives/`
@@ -1,26 +0,0 @@
-# [LOG] Skybound Asset Purity & Transparency Synchronization
-
- **Timestamp**: 2026-04-23 22:52 (KST)
- **Status**: Completed
- **Lead**: Steve (Executive Director)
-
-## 1. 작업 내용 (Task Summary)
- **스프라이트 자산 교체**: 사용자 기체(Falcon, Rayce), 일반 적기(Normal), 엘리트 적기(Elite), 보스 적기(Boss)의 이미지를 배경이 제거된 고해상도 PNG로 전면 교체.
- **렌더링 로직 최적화**: `SpriteUtils.ts`의 `loadTransparentSprite` 함수 내에서 해당 에셋들이 'Fake Transparency Removal' 로직을 거치지 않고 원본 알파 채널을 그대로 사용하도록 화이트리스트 업데이트.
-
-## 2. 작업 이유 (Rationale)
- **미학적 완성도**: 대표님(Yesung)께서 직접 가공하신 배경 없는 고해상도 에셋의 무결성을 100% 보존하기 위함.
- **성능 최적화**: 픽셀 단위의 색상 비교 및 배경 제거 연산(Flood-fill style algorithm)은 CPU 자원을 소모함. 이미 투명 배경이 확보된 에셋에 대해 이를 수행하는 것은 'Shit'이며, 이를 제거함으로써 로딩 속도와 런타임 효율성을 확보함.
-
-## 3. 수정된 코드 (Code Changes)
- **Target File**: `/Volumes/Data/project/Antigravity/Skybound/src/features/game/utils/SpriteUtils.ts`
- **변경 사항**: `trueTransparencyAssets` 배열에 `'normal_enemy'`, `'elite_enemy'`, `'boss'` 키워드 추가. 이를 통해 해당 경로를 포함하는 모든 에셋은 원본 투명도를 신뢰하고 즉시 로딩됨.
-
-## 4. 왜 했는가 (Why It Matters)
- **Zero-Tolerance for Mediocrity**: 도구가 창작자의 의도를 훼손하게 두지 않기 위함. 엔진은 창작자가 제공한 완벽한 재료를 가장 순수한 상태로 유저에게 전달해야 함.
- **System Integrity**: 에셋의 상태(Transparent vs Solid)에 따라 처리 파이프라인을 분기함으로써 시스템의 유연성과 전문성을 강화함.
-
-## 5. 관련 토픽 (Linked Topics)
- Skybound: 프로젝트 전체 에셋 관리 표준 수립.
- Graphics & Performance: 불필요한 이미지 프로세싱 오버헤드 제거.
- Design & Experience: 픽셀 퍼펙트한 실루엣을 통한 게임 몰입감 증대.
@@ -1,21 +0,0 @@
-# [LOG] Skybound Enemy Orientation Fix (Crab Movement Bug)
-
- **Timestamp**: 2026-04-23 23:13 (KST)
- **Status**: Resolved
- **Lead**: Steve (Executive Director)
-
-## 1. 버그 내용 (Bug Description)
- **현상**: 적기가 화면 상단에서 등장할 때 정면(아래)을 보지 않고 오른쪽을 바라본 채 하강하는 '꽃게 이동' 현상 발생.
- **원인**: 적기 생성 시 `rotation` 초기값이 `0`이었으며, 등장 단계(Entrance)에서 플레이어를 조준하는 로직이 조기 종료(Early Return)로 인해 실행되지 않아 렌더링 오프셋(`+PI/2`)만 적용되어 오른쪽을 바라보게 됨.
-
-## 2. 해결 방법 (Resolution)
- **초기화 강화**: `SpawnerSystem`에서 적기 생성 시 `rotation: Math.PI / 2`를 기본값으로 명시적 할당.
- **로직 순서 재조정**: `CombatSystem`의 업데이트 루프에서 회전값 계산을 등장 단계 분기점 이전으로 전진 배치하여, 어떤 상태에서도 적기가 플레이어 방향(또는 아래 방향)을 유지하도록 보장.
-
-## 3. 결과 (Expected Result)
- 적기가 생성되는 즉시 플레이어를 향해 정면을 유지하며 하강함.
- 시각적 직관성 및 전투 몰입도 향상.
-
-## 4. 관련 토픽 (Linked Topics)
- Skybound: 엔진 렌더링 무결성 확보.
- Graphics & Performance: 스프라이트 회전 행렬 최적화.
@@ -1,25 +0,0 @@
---
-category: Other
-tags: [auto-wikified, technical-documentation, other]
-title: Static Site Generation (SSG)
-description: "Static Site Generation (SSG)는 애플리케이션을 빌드하고 배포하는 과정에서 여러 라우트에 대한 HTML을 사전에 렌더링(pre-render)하여 생성하는 기술이다 [1, 2]."
-last_updated: 2026-05-04
---
-
-# Static Site Generation (SSG)
-
-## 📌 Brief Summary
-Static Site Generation (SSG)는 애플리케이션을 빌드하고 배포하는 과정에서 여러 라우트에 대한 HTML을 사전에 렌더링(pre-render)하여 생성하는 기술이다 [1, 2]. 이는 서버 사이드 렌더링(SSR)의 하위 변형(sub-variant)으로 간주되며, 런타임에 서버가 요청을 처리할 필요 없이 빌드 시점에 정적 HTML 파일들을 만들어 원하는 곳에 호스팅할 수 있게 해준다 [1, 3].
-
-## 📖 Core Content
-* **빌드 타임 렌더링 (Build-time Rendering):** SSG는 사용자의 요청이 들어올 때마다 실시간으로(on-demand) 화면을 구성하는 대신, 애플리케이션을 컴파일하고 빌드하는 단계에서 미리 HTML을 생성한다 [1-3].
-* **Next.js 환경의 기본 동작:** Next.js의 App Router 환경에서는 실시간 데이터 처리가 반드시 필요한 경우가 아니라면, 기본적(by default)으로 빌드 타임에 이러한 정적 사이트 생성 작업이 수행된다 [3]. 프레임워크 수준에서 점진적 정적 재생성(Incremental Static Regeneration)과 같은 기능을 지원하여 복잡한 애플리케이션의 성능과 확장성 확보에도 기여한다 [4].
-* **React Server Components (RSC)와의 시너지:** React Server Components는 렌더링 시점에 따라 동적 생성(on-demand)뿐만 아니라 빌드 시점(during the build)에도 실행될 수 있다 [3]. 따라서 RSC를 활용해 런타임 서버 없이도 다수의 정적 HTML 파일을 생성하고 호스팅하는 방식의 아키텍처를 구성할 수 있다 [3].
-
-## ⚖️ Trade-offs & Caveats
-* **자바스크립트 종속성과 하이브리드 라우팅:** Next.js와 같은 프레임워크 환경에서 SSG와 RSC를 사용할 때, 완전히 자바스크립트가 배제된(truly static no-JS) 순수 정적 웹사이트를 구축하는 것은 프레임워크의 특성상 제약이 따른다 [5]. 이는 Next.js 프레임워크 자체에 라우팅 등을 관리하기 위해 클라이언트 측에서 실행되어야 하는 필수 코드가 포함되어 있기 때문이다 [5].
-* **사용자 경험(UX) 최적화라는 반대 급부:** 정적 페이지임에도 클라이언트 자바스크립트가 필요한 구조는 오히려 사용자 경험을 향상시키는 반대 급부를 제공한다 [5]. 잘 구조화된 애플리케이션은 자바스크립트가 다운로드되는 동안에도 정상적으로 동작하며, 로드가 완료된 후에는 프레임워크의 라우터가 일반적인 `<a>` 태그보다 더 빠르게 탐색을 처리하게 된다 [5].
-* 이 외에 SSG 도입 시 발생할 수 있는 구체적인 단점이나 여타 제약 사항에 대해서는 소스에 관련 정보가 부족합니다.
-
---
-*Last updated: 2026-05-03*
@@ -1,24 +0,0 @@
---
-category: Architecture
-tags: [auto-wikified, technical-documentation, architecture]
-title: Value Objects
-description: "소스에 관련 정보가 부족합니다."
-last_updated: 2026-05-04
---
-
-# Value Objects
-
-## 📌 Brief Summary
-소스에 관련 정보가 부족합니다.
-
-## 📖 Core Content
-소스에 관련 정보가 부족합니다. 
-
-제공된 소스에서는 헥사고날 아키텍처(Hexagonal Architecture)와 도메인 주도 설계(DDD)를 기반으로 하는 프로젝트의 도메인 영역 내에 값 객체(Value Objects)를 둘 수 있다는 점만 언급되어 있습니다 [1]. 외부 유효성 검사 라이브러리(예: Jakarta validation) 대신 이 값 객체들을 통해 유효성 검사(validation)를 처리할 수 있는지에 대한 개발자의 질문 형태로 짧게 등장할 뿐, 상세한 정의나 구조적 특징에 대한 내용은 포함되어 있지 않습니다 [1].
-
-## ⚖️ Trade-offs & Caveats
-소스에 관련 정보가 부족합니다.
-
-
---
-*Last updated: 2026-05-03*
@@ -1,29 +0,0 @@
-# 🌙 오토 플래너
-
-트렌드 스나이퍼를 정해진 간격으로 반복 실행해서 패턴 데이터를 쌓아주는 무인 작업자예요. 한 번 트렌드를 보면 지금 잘 되는 영상 한 장만 보이지만, 8시간 동안 2시간마다 4번 보면 "어떤 키워드의 후크가 시간이 지나도 계속 살아남는지"가 보이기 시작합니다 — 자는 동안에 그 작업을 대신해줍니다.
-
-## 어떻게 도와주나요?
- ⏰ N시간마다 `trend_sniper.py`를 자동 실행 (스나이퍼 결과는 매번 sessions/에 누적)
- 🛌 잘 때 켜두면 아침에 4~5번분의 트렌드 스냅샷이 쌓여 있어요
- 📊 같은 키워드라도 시간대별로 어떤 영상이 새로 떠오르는지 비교 가능
-
-## 어떤 상황에 켜면 좋나요?
- 새 채널 컨셉을 결정하기 전, 며칠치 트렌드를 누적해서 보고 싶을 때
- 회사 일/외출 중 백그라운드에서 데이터만 모아두고 싶을 때
- 특정 키워드의 알고리즘 반응이 시간대마다 다른지 확인하고 싶을 때
-
-## 시작하기 전 체크
- 트렌드 스나이퍼 도구가 먼저 설정돼 있어야 해요 (YouTube API 키, 키워드 목록 등)
- 첫 실행 전에 트렌드 스나이퍼를 한 번 수동으로 돌려서 정상 작동 확인을 권장합니다
-
-## 설정값 (auto_planner.json)
- `INTERVAL_HOURS` — 몇 시간마다 실행할지 (기본 2)
- `TOTAL_RUN_HOURS` — 총 가동 시간 (기본 8 → 8시간 동안 4회 실행)
-
-## 실행 방법
-패널의 [▶ 실행]을 누르면 시작됩니다. 또는 터미널에서:
-```bash
-python auto_planner.py
-```
-
-⚠️ 이 스크립트는 끝날 때까지 터미널을 점유해요. 백그라운드로 돌리려면 별도 창에서 실행하세요. 중단하려면 Ctrl+C.
@@ -1,24 +0,0 @@
---
-category: Backend
-tags: [auto-wikified, technical-documentation, backend]
-title: class-validator
-description: "`class-validator`는 NestJS 아키텍처 내에서 컨트롤러(Controller)가 사용하는 데이터 전송 객체(DTO, Data Transfer Object)의 유효성을 검사하는 데 사용되는 도구입니다 [1]."
-last_updated: 2026-05-04
---
-
-# class-validator
-
-## 📌 Brief Summary
-`class-validator`는 NestJS 아키텍처 내에서 컨트롤러(Controller)가 사용하는 데이터 전송 객체(DTO, Data Transfer Object)의 유효성을 검사하는 데 사용되는 도구입니다 [1]. 제공된 소스에서는 DTO 검증 목적에 대한 단편적인 언급 외에 3~5문장 분량의 상세한 정의를 구성할 수 있는 관련 정보가 부족합니다.
-
-## 📖 Core Content
-소스에 관련 정보가 부족합니다. 
-
-(참고: 소스 내에서는 NestJS 프로젝트 구조를 설명할 때, DTO 파일들이 `<feature>/dto/` 디렉토리에 위치하며 `class-validator`를 통해 검증된 후 컨트롤러에서 사용된다는 한 가지 사실만 언급되어 있습니다 [1].)
-
-## ⚖️ Trade-offs & Caveats
-소스에 관련 정보가 부족합니다.
-
-
---
-*Last updated: 2026-05-03*
@@ -1,23 +0,0 @@
-# 🔑 계정 / 채널 (공유 설정)
-
-여기 한 번만 채워두면 다른 모든 YouTube 도구(트렌드 스나이퍼·내 영상 체크·댓글 수집기·경쟁 채널 분석·텔레그램 보고)가 이 값을 그대로 가져다 씁니다. 매번 도구마다 같은 키를 넣지 않아도 돼요.
-
-## 채워야 하는 항목
-
-| 키 | 설명 | 채우는 법 |
-|---|---|---|
-| `YOUTUBE_API_KEY` | YouTube Data API v3 키 | [console.cloud.google.com](https://console.cloud.google.com/) → 프로젝트 → "YouTube Data API v3" 사용 설정 → 사용자 인증 정보 → API 키. 무료 한도 충분(하루 10,000 단위). |
-| `MY_CHANNEL_HANDLE` | 본인 채널 @핸들 | 예: `@mychannel`. 핸들 또는 ID 둘 중 하나만 채우면 됨. |
-| `MY_CHANNEL_ID` | 본인 채널 ID (UCxxxx) | 핸들로 못 잡힐 때 백업용. studio.youtube.com → 설정 → 채널에서 확인. |
-| `WATCHED_CHANNELS` | 댓글 수집 대상 채널 핸들 목록 | 예: `["@channel_a", "@channel_b"]`. 댓글 수집기가 이 채널들 최근 영상의 댓글을 메모리로 가져옵니다. |
-| `COMPETITOR_CHANNELS` | 경쟁 채널 분석 대상 | 같은 형식. 경쟁 채널 분석 도구가 패턴을 뽑아 다음 액션을 추천합니다. |
-| `TELEGRAM_BOT_TOKEN` | 텔레그램 봇 토큰 | @BotFather에서 /newbot으로 봇 만들고 받은 `123:ABC...` 형식 토큰. 비워두면 보고 알림 OFF. |
-| `TELEGRAM_CHAT_ID` | 본인 chat_id | 봇한테 아무 메시지 보낸 뒤 `https://api.telegram.org/bot<TOKEN>/getUpdates` 열어서 `chat.id` 확인. |
-| `OLLAMA_URL` | 로컬 LLM 주소 | 기본 `http://127.0.0.1:11434`. LM Studio면 보통 `http://127.0.0.1:1234`. |
-| `MODEL` | 분석에 쓸 모델 이름 | 비워두면 첫 번째로 발견된 모델을 자동 선택. |
-
-## 실행하면?
-입력값이 제대로 들어왔는지 확인 리포트만 출력합니다 (실제 데이터 호출 X). 키가 비어있으면 알려줍니다.
-
-## 어디 저장되나?
-이 폴더의 `youtube_account.json` 한 파일에. 브레인 폴더 안이라 GitHub 백업도 같이 됩니다.