Refactor: Consolidate directory structure into 5 main categories and update metadata
This commit is contained in:
Antigravity Agent
-23
@@ -1,23 +0,0 @@
|
||||
# Engine Stability and [[Optimization|Optimization]] (2026-04-21)
|
||||
|
||||
Skybound 엔진의 성능 저하 및 런타임 크래시 이슈에 대한 해결 및 방지 가이드입니다.
|
||||
|
||||
## 1. Issue: Effect Overload (이펙트 폭주)
|
||||
- **증상**: 대폭발 시 수백 개의 파편(Shard) 객체가 화면에 잔존하여 프레임 드랍 발생.
|
||||
- **해결책**:
|
||||
- **Hard Cap**: 파편 최대 생성 개수를 500개로 제한.
|
||||
- **Resource Recycling**: 파편의 수명 감소 속도를 6배 상향(0.1 -> 0.6)하여 자원 회수율 증대.
|
||||
|
||||
## 2. Issue: Rendering and API Type Mismatch
|
||||
- **증상**: `undefined` 배열 순회 시 발생하는 런타임 에러.
|
||||
- **해결책**:
|
||||
- **Optional Chaining**: `GameRenderer.ts` 내 모든 엔티티 순회 로직에 `?.` 및 `|| []` 적용.
|
||||
- **Interface Sync**: `WorldModel`에 `items`, `expGems` 등 누락된 필드를 정식 등록하여 정적 분석 강화.
|
||||
|
||||
## 3. Lesson Learned (조직적 교훈)
|
||||
- **Silo Warning**: 엔진 고도화 중 인터페이스 명세서를 동시에 업데이트하지 않을 경우, '느슨한 계약 관리'로 인해 대규모 런타임 에러가 발생할 수 있음.
|
||||
- **Defensive Programming**: 외부 주입 데이터가 언제든 `undefined`일 수 있음을 가정하고 순회 로직을 작성해야 함.
|
||||
|
||||
---
|
||||
**Status**: Resolved
|
||||
**Context**: Infrastructure / Performance Tuning
|
||||
-32
@@ -1,32 +0,0 @@
|
||||
# Skybound Implementation and [[Architecture|Architecture]] Report (V10.5)
|
||||
|
||||
Skybound 프로젝트의 Phase 2 인프라 고도화 결과를 기록한 통합 보고서입니다.
|
||||
|
||||
## 1. Core Architecture (마스터 타임라인)
|
||||
시스템은 시간의 흐름에 따라 긴장감을 제어하는 **4단계 페이즈 시스템**(`StageDirectorSystem`)을 채택하고 있습니다.
|
||||
|
||||
| 페이즈 | 시간 | 주요 특징 |
|
||||
| :--- | :--- | :--- |
|
||||
| **INTRO** | 0~3분 | 기초 파밍 및 적응 단계 |
|
||||
| **ELITE_PRESS** | 3~7분 | 정예 기체 중심의 압박 |
|
||||
| **SWARM** | 7~12분 | 대규모 물량 습격 (Survivor-like) |
|
||||
| **FINAL_BOSS** | 12분~ | 최종 결전 시퀀스 |
|
||||
|
||||
## 2. Evo-Engine Mechanics (데이터 기반 진화)
|
||||
데이터(Registry)와 로직(Engine)을 분리하여 확장성을 확보했습니다.
|
||||
- **SKILL_REGISTRY**: 스킬 메타데이터 중앙 관리 허브.
|
||||
- **Evolution Recipe**: 특정 주무기(Lv.5)와 보조 모듈의 조합을 통한 상위 티어 진화 공식 정의.
|
||||
|
||||
## 3. High-[[Dopamine|Dopamine]] FeedbackSystem
|
||||
유저의 시각적/촉각적 몰입을 극대화하기 위한 연출 가이드입니다.
|
||||
- **Red Critical & Screen Shake**: 타격 시 텍스트 연출과 흔들림 이펙트.
|
||||
- **Glitch Effect**: 진화 성공 시의 강렬한 연출.
|
||||
|
||||
## 4. Meta-Game Economy (순환 구조)
|
||||
장비의 합성(`NORMAL` ~ `ETERNAL`)과 분해를 통한 자원 회수 루프를 구축하였습니다.
|
||||
- **Triple Merge**: 동일 등급 3개 합성 방식.
|
||||
- **Core Extraction**: S급 장비 분해를 통한 상위 제작 재화 확보.
|
||||
|
||||
---
|
||||
**Status**: Approved (2026-04-21)
|
||||
**Lead**: AI 개발부장 '코다리'
|
||||
-26
@@ -1,26 +0,0 @@
|
||||
# Project Report V11.5: Combat and UI Recovery (2026-04-21)
|
||||
|
||||
Skybound 프로젝트의 치명적인 결함을 복구하고 유저 인터페이스를 고도화한 통합 개발 보고서입니다. 🟢 [NOMINAL]
|
||||
|
||||
## 1. Combat Engine Recovery (전투 엔진 복구)
|
||||
현장 QA에서 발견된 핵심 결함들을 즉각 조치하였습니다.
|
||||
|
||||
- **Exp-Gems Drop**: 적 처치 시 경험치 보석이 드랍되지 않던 현상을 `CombatSystem.ts` 수정을 통해 해결.
|
||||
- **Engine Synchronization**: 레벨업 UI에서의 선택 사항이 `useGameEngine.ts`에 즉시 반영되지 않던 채널 장애 복구.
|
||||
- **Starter Loadout**: 초반 무기 부재 문제를 해결하기 위해 **'Gatling Gun Lv.1'**을 모든 기체에 기본 장착 사양으로 고정.
|
||||
|
||||
## 2. UI/UX [[Innovation|Innovation]] (직관성 강화)
|
||||
유저의 정보 인지 속도를 높이기 위한 시각적 개선 작업을 수행했습니다.
|
||||
|
||||
- **[[Terminology|Terminology]] Standardization**: 스토리지의 모호한 약자(A, E)를 **Armor, Engine** 등 명확한 전문 용어로 전면 교체.
|
||||
- **Acquisition Alerts**: 신규 모듈 획득 시 등급별 고유 색상(Tier-Colored)과 애니메이션이 포함된 알림 노출.
|
||||
- **New Indicator**: 창고 내 미확인 아이템에 **'NEW'** 뱃지 및 발광(Glow) 효과 적용.
|
||||
|
||||
## 3. Infrastructure & [[Roadmap|Roadmap]]
|
||||
- **Git Automation**: 작업 완료 즉시 커밋 및 푸시가 이행되는 자동화 파이프라인 구축.
|
||||
- **Next Step**: 드론 병합(Merge) 및 아트 리소스 실장(Real-Asset Loading) 작업 예정.
|
||||
|
||||
---
|
||||
**Status**: Critical Recovery Complete
|
||||
**Reviewer**: AI 개발부장 '코다리' 🫡🐟
|
||||
**Tags**: #Stability_QA #Dopamine_UX #Core_[[Logic|Logic]]
|
||||
@@ -1,24 +0,0 @@
|
||||
# UX and [[Dopamine|Dopamine]] Feedback Upgrade (V10.0)
|
||||
|
||||
단순한 발사 로직을 넘어, 유저에게 강렬한 피드백을 전달하기 위한 설계 사양입니다.
|
||||
|
||||
## 1. Probabilistic Critical Hit (슬롯머신 경험)
|
||||
- **공식**: `damage *= 1.5 + Math.pow(Math.random(), 3) * 3.5`
|
||||
- **심리적 효과**: Cubic Power를 사용하여 초고속 데미지가 극도로 희귀하게 발생하게 함으로써, 소위 '잭팟(Jackpot)' 효과 유도.
|
||||
|
||||
## 2. Visual Feedback Engine
|
||||
타격의 세기에 따라 시각적 계층을 분리했습니다.
|
||||
- **Normal**: 작은 흰색 숫자 출력.
|
||||
- **Critical**: 대형 황금색 "CRITICAL!" 텍스트 및 `shadowBlur` 이펙트(부유 후 페이드아웃).
|
||||
|
||||
## 3. Difficulty Scaling Algorithm
|
||||
플레이어가 지루함을 느끼지 않도록 시간이 지날수록 난이도를 복리로 상승시킵니다.
|
||||
- **Factor**: `difficultyMult = 1.0 + (frame / 3600) * 0.1`
|
||||
- **영향 범위**: 적 생성 쿨다운 감소, 적 HP 상승, 환경 장애물(Asteroids) 보정률 상승.
|
||||
|
||||
## 4. Policy: FALCON Streamlining
|
||||
통계적 밸런싱의 용이성을 위해 현재 주력 기체를 `FALCON`으로 단일화하고 집중 케어합니다.
|
||||
|
||||
---
|
||||
**Status**: Verified High-Dopamine Content
|
||||
**Category**: Game Design / User Experience
|
||||
-32
@@ -1,32 +0,0 @@
|
||||
# ⚡ Skybound: Stability & [[Optimization|Optimization]] Report (2026-04-21)
|
||||
|
||||
## 1. Executive Summary (요약)
|
||||
대규모 교전 및 아이템 사용 시 발생하는 성능 저하와 런타임 크래시를 해결하기 위한 엔진 안정성 보강 작업을 수행하였습니다.
|
||||
|
||||
## 2. Key Optimization Areas (주요 최적화 영역)
|
||||
|
||||
### 💥 Particle Effect [[Management|Management]] (이펙트 제어)
|
||||
- **Problem**: 폭탄 사용 시 수천 개의 파편(Shard) 객체가 생성되어 FPS 급락.
|
||||
- **[[Solution|Solution]]**:
|
||||
- **Hard Cap**: 최대 파티클 개수를 500개로 제한.
|
||||
- **TTL (Time To Live) Acceleration**: 파티클 소멸 속도를 6배 상향(0.1 -> 0.6)하여 자원 회수 주기를 단축.
|
||||
|
||||
### 🛡️ Runtime [[Robustness|Robustness]] (런타임 강건성)
|
||||
- **Problem**: 존재하지 않는 엔티티 배열 접근으로 인한 `TypeError`.
|
||||
- **Solution**:
|
||||
- `GameRenderer` 내 모든 순회 로직에 옵셔널 체이닝(`?.`) 및 기본값(`|| []`) 처리 의무화.
|
||||
- 인터페이스(`types.ts`)와 실제 상태 객체 간의 동기화 정밀 검수.
|
||||
|
||||
### 🔄 Entity Pool Intelligence (엔티티 풀 고도화)
|
||||
- **Problem**: ID(String)와 객체 참조 간의 혼선으로 인한 해제 실패.
|
||||
- **Solution**:
|
||||
- `EntityManager`에 `releaseById` 메서드 추가.
|
||||
- 객체 여부와 관계없이 안전하게 리소스를 반납할 수 있는 추상화 레이어 구축.
|
||||
|
||||
## 3. Post-Mortem (사후 분석)
|
||||
- **Silo Effect**: 엔티티 매니저 도입과 같은 대규모 인프라 변경 시, 관련 인터페이스를 동시에 업데이트하지 않아 발생한 '느슨한 계약(Loose Contract)' 문제가 근본 원인이었습니다.
|
||||
- **Guideline**: 시스템 간 데이터 교환 방식(ID 기반 vs 참조 기반)을 프로젝트 표준으로 확정하고 준수해야 합니다.
|
||||
|
||||
---
|
||||
**Related Cluster**: Performance Tuning
|
||||
**Status**: Verified by QA 🫡
|
||||
-39
@@ -1,39 +0,0 @@
|
||||
# ⚙️ Engine [[Logic|Logic]] [[Optimization|Optimization]] & Modernization
|
||||
|
||||
**Category:** [[Architecture|Architecture]] / [[Physics|Physics]]
|
||||
**Status:** Completed (v12.1)
|
||||
**Related:** Engine Loop, 03_Boss_systems/[[Boss_Encounter_and_Timeline_Design|Boss Encounter Design]]
|
||||
|
||||
---
|
||||
|
||||
## 1. Tactical Logical Modernization
|
||||
Skybound의 초기 '무작위성' 중심 로직을 '의도된 연출' 중심으로 전환한 핵심 최적화 내역입니다.
|
||||
|
||||
### 🛡️ Reactive Stat Sync (실시간 스탯 동기화)
|
||||
- **메커니즘**: `useGameStore.subscribe`를 통해 장비 교체나 영구 업그레이드 발생 시, 엔진의 `effectiveStats`를 런타임에 즉시 재계산.
|
||||
- **효과**: "인벤토리에서 공격력을 올렸는데 왜 바로 강해지지 않는가?"라는 모순을 해결.
|
||||
|
||||
### 🛰️ Priority-Based Spawning (우선순위 기반 스폰)
|
||||
- **Logic**: 하드캡(`MAX_ENEMIES_HARD_CAP`) 도달 시, `ELITE` 이상의 등급은 일반 적(`NORMAL`)을 **강제 퇴거(Despawn)**시키고 자리를 확보함.
|
||||
- **효과**: 물량에 밀려 보스가 등장하지 못하는 치명적인 결함 방지.
|
||||
|
||||
---
|
||||
|
||||
## 2. Combat Physics & HP Revamp
|
||||
|
||||
### 📏 100-Base HPSystem
|
||||
- **구형**: 하트 5칸 기반의 단순 생명력 시스템 (회복 및 성장 가시성 낮음).
|
||||
- **신규**: 100 기준의 체력 시스템으로 통합하여 퍼센트 단위 회복 및 영구 HP 업그레이드 반영이 가능하도록 구조화.
|
||||
|
||||
### 💥 Mutual Knockback (물리 충돌)
|
||||
- 단순히 겹칠 때 대미지를 입는 방식에서 벗어나, 충돌 벡터(`vx`, `vy`)를 기반으로 서로 밀려나는 물리 작용 구현.
|
||||
- **타격감**: 기체 간 충돌 시의 '묵직함' 확보.
|
||||
|
||||
---
|
||||
|
||||
## 3. Engagement Compression
|
||||
- **Blitz Mode**: 보스 출현 시간을 **60초**로 단축하여 파밍 효율 극대화.
|
||||
- **Standard Mode**: 보스 조우 타임라인을 **2분**으로 압축하여 검증 및 플레이 텐션 강화.
|
||||
|
||||
---
|
||||
**Last Updated:** 2026-04-22 🫡
|
||||
@@ -1,38 +0,0 @@
|
||||
# 🔍 Skybound 엔진 구조 정밀 감사 보고서 (V12.1)
|
||||
|
||||
> **카테고리**: Skybound, Software [[Reliability|Reliability]], Governance & Reliability
|
||||
> **상태**: ✅ 감사 완료 (Audited)
|
||||
> **최종 업데이트**: 2026-04-22
|
||||
|
||||
---
|
||||
|
||||
## 📌 개요 (Overview)
|
||||
엔진 안정성에 대한 의구심(코드 잘림, 상태 단절 등)이 제기됨에 따라, 전체 시스템 파이프라인(ECS-like Update, Zustand Sync, Progression Flow)을 전수 조사하여 아키텍처적 건전성을 검증함.
|
||||
|
||||
## 📊 감사 요약 (Audit Summary)
|
||||
|
||||
| 이슈 항목 | 실제 상태 | 심각도 | 판정 결과 |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **#1 Engine Execution Gap** | **정상** — `ctx` 객체 완전 구성됨 | 🟢 Low | 단순 파일 읽기 초과로 인한 오판 |
|
||||
| **#2 [[State|State]]-[[Physics|Physics]] Disconnect** | **정상** — `setExp/setLevel` 액션 완결 | 🟢 Low | 15프레임 Dirty Checking 동기화 확인 |
|
||||
| **#3 Gimmick Manager 빈 껍데기** | **부분 유효** — 구현 완료, 타입 불일치 1건 | 🟡 Med | `spawnParticle` 인자 불일치 수정 완료 |
|
||||
| **#4 Collision-to-EXP 미연결** | **정상** — Combat → Progression 연결됨 | 🟢 Low | Gem 수집부터 카드 생성까지 연결 확인 |
|
||||
|
||||
## 🛠️ 정밀 분석 (Detailed [[Analysis|Analysis]])
|
||||
|
||||
### 1. 엔진 컨텍스트 (`ctx`) 및 루프 구조
|
||||
- **Context Inte[[Grit|Grit]]y**: `useGameEngine.ts` 내에서 플레이어, 상태, 입력, 엔티티 매니저 및 각종 스폰 함수가 `ctx` 객체에 완전히 맵핑되어 각 시스템에 전달되고 있음.
|
||||
- **Loop Flow**: `StageDirector` → `System [[Logic|Logic]]` → `Combat/Progression` → `Renderer` 순의 고전적 ECS 파이프라인이 매 프레임(60FPS) 정상 작동함.
|
||||
|
||||
### 2. 상태 관리 브릿지 (Store Sync)
|
||||
- **Zustand Interface**: 엔진 내부 상태(`state.currentExp` 등)와 외부 UI 스토어(`useGameStore`) 간의 데이터 동기화는 `useGameEngine.ts`에서 15프레임마다 수행되는 브릿지 로직을 통해 효율적으로 관리됨 (불필요한 React Re-render 방지).
|
||||
|
||||
### 3. 실제 수정 사항 (Bug Fix)
|
||||
- **GravityGimmick.ts**: `ctx.spawnParticle` 호출 시 엔진 시그니처와 불일치하는 5번째 인자(`'DIR'`)가 전달되는 문제를 식별하여 제거함. 이는 시스템 오류를 유발하지는 않으나 타입 정결성을 위해 조치됨.
|
||||
|
||||
## 📋 최종 결론
|
||||
Skybound 엔진은 **구조적으로 건강하며, 모든 핵심 파이프라인이 완전히 구현된 상태**임. 향후 확장을 위한 아키텍처적 기반(Intent Protocol, Signal Pattern)이 견고하게 구축되어 있음을 확인함.
|
||||
|
||||
---
|
||||
**승인인**: AI 개발부장 코다리 🫡
|
||||
**관련 문서**: 02_[[Architecture|Architecture]]_Principles, [[Visual_Feedback_Signal_Pattern|Visual_Feedback_Signal_Pattern]]
|
||||
@@ -1,34 +0,0 @@
|
||||
# POST-MORTEM: Skybound Meta-Game Stabilization & Loot Economy Overhaul (2026-04-23)
|
||||
|
||||
## 1. 프로젝트 개요
|
||||
보스전 이후 스테이지 전이가 멈추는 치명적 버그를 해결하고, 기획안에 맞춘 전리품(Loot) 경제 밸런스 재조정 및 보급품 시스템의 논리적 결함을 수정한 포스트모텀.
|
||||
|
||||
## 2. 주요 해결 과제 및 분석 (Key Issues)
|
||||
|
||||
### 2.1 보스 처치 후 진행 불가 (Stage Progression Stall)
|
||||
- **현상**: 보스를 처치하고 폭발 연출까지 완료되었으나, 다음 스테이지로 넘어가지 않고 화면에 갇히는 현상.
|
||||
- **원인**: `StageDirectorSystem`에서 보스 사망 시 `NEXT_STAGE` 이벤트를 발행했으나, 엔진의 메인 루프(`useGameEngine`)에 해당 이벤트를 수신하여 UI/상태를 전환하는 핸들러가 누락되어 있었음.
|
||||
- **해결**: `useGameEngine.ts`의 `emitEvent` 리스너에 `BOSS_ACTION: NEXT_STAGE` 케이스를 추가하고, `finishMission('CLEAR', ...)`을 호출하도록 연결.
|
||||
|
||||
### 2.2 전리품 드롭 확률 불균형 (Loot Economy Inflation)
|
||||
- **현상**: 보스 처치 시 무조건 S급 아이템이 나오거나, 일반 적들의 드롭률이 너무 높아 아이템 희소성이 결여됨.
|
||||
- **원인**: `LootGenerator.ts` 내부에 하드코딩된 확률 임계값이 초기 테스트용으로 과하게 설정되어 있었음.
|
||||
- **해결**: 대표님 제시안에 맞춰 보스 드롭률을 **67%**로 제한하고, 등급별 확률(S: 5%, Epic: 1% 등)을 정밀 재조정함. 엘리트 및 일반 적의 드롭률도 대폭 하향하여 파밍의 재미를 강화.
|
||||
|
||||
### 2.3 보급 상자 '가짜 업그레이드' (Phantom Upgrades)
|
||||
- **현상**: 보급 상자(Chest)를 통해 무기를 골라도 실제 무기 레벨이 오르지 않아, 겉모습만 레벨업인 상태(레벨 3에서 무한 업그레이드 느낌)가 지속됨.
|
||||
- **원인**: UI(`GameSceneRenderer`)에서 `isChest` 플래그가 활성화된 경우, "레벨업이 아니므로 스킬을 적용하지 않는다"는 잘못된 방어 로직이 적용되어 있었음.
|
||||
- **해결**: `isChest` 유무와 관계없이 선택된 스킬을 엔진과 스토어에 적용(`addSkill`, `applySkill`)하도록 수정하여 보급 상자의 실질적 효용성 확보.
|
||||
|
||||
## 3. 잘된 점 (What Went Well)
|
||||
- **신속한 원인 파악**: 엔진 이벤트 루프와 UI 상태 간의 단절 지점을 정확히 찾아내어 최소한의 코드 수정으로 버그 해결.
|
||||
- **기획 충실도**: 텍스트로 전달된 복잡한 확률 테이블을 엔진 코드에 오차 없이 반영.
|
||||
- **동기화 성공**: 엔진 내부 상태와 Zustand 글로벌 스토어 간의 싱크를 맞춰 '가짜 업그레이드' 현상을 원천 해결.
|
||||
|
||||
## 4. 교훈 및 향후 과제 ([[Lessons Learned|Lessons Learned]] & Next Steps)
|
||||
- **이벤트-리스너 쌍 검증**: 새로운 시스템 이벤트를 정의할 때 반드시 수신 측(Listener)이 구현되었는지 체크리스트화 필요.
|
||||
- **UI/엔진 역할 분담**: `isChest`와 같은 상태 플래그가 비즈니스 로직(스킬 적용)까지 차단하지 않도록 설계 시 주의.
|
||||
- **모니터링 강화**: 현재 확률에 따른 드롭 현황을 로깅하여 장기적인 밸런싱 데이터 확보 예정.
|
||||
|
||||
## 5. 결론
|
||||
이번 안정화 작업을 통해 Skybound의 **'전술적 긴장감'**과 **'성장 루프'**가 정상 궤도에 진입함. 보스전 - 보급 - 스테이지 전환으로 이어지는 핵심 게임 루프의 기술적 무결성 확인 완료. 🫡🐟
|
||||
@@ -1,10 +0,0 @@
|
||||
# Index: Topics > Skybound > 05_Project_Issues
|
||||
|
||||
## 📝 Documents
|
||||
- [[2026-04-21-Engine-Stability-and-Optimization|2026-04-21-Engine-Stability-and-Optimization]]
|
||||
- [[2026-04-21-Implementation-and-Architecture-Report|2026-04-21-Implementation-and-Architecture-Report]]
|
||||
- [[2026-04-21-Project-Report-V11.5-Combat-and-UI-Recovery|2026-04-21-Project-Report-V11.5-Combat-and-UI-Recovery]]
|
||||
- [[2026-04-21-UX-Dopamine-Feedback-Upgrade|2026-04-21-UX-Dopamine-Feedback-Upgrade]]
|
||||
- [[2026-04-22_Engine_Logic_Optimization_Report|2026-04-22_Engine_Logic_Optimization_Report]]
|
||||
- [[2026-04-22_Engine_Stability_Audit|2026-04-22_Engine_Stability_Audit]]
|
||||
- [[Issue-001-Combat-Reference-Error-Troubleshooting|Issue-001-Combat-Reference-Error-Troubleshooting]]
|
||||
-22
@@ -1,22 +0,0 @@
|
||||
# Issue #001: CombatSystem [[Reference|Reference]]Error (Case Study)
|
||||
|
||||
개발 중 발생한 변수 선언 누락으로 인한 시스템 크래시 사례 분석입니다.
|
||||
|
||||
## 1. Problem Definition
|
||||
- **장애 요약**: 적 피격 시 `damage is not defined` 에러로 엔진이 중단됨.
|
||||
- **오류 지점**: `CombatSystem.ts` 내 데미지 연산 블록.
|
||||
|
||||
## 2. Root Cause (원인 분석)
|
||||
대규모 리팩토링 과정에서 VFX 로직에만 치우친 나머지, 변수의 생명주기(Scope)를 결정하는 선언부(`let/const`)를 누락함. 자바스크립트의 런타임 특성상 선언되지 않은 변수 참조는 예외 없이 크래시로 이어짐.
|
||||
|
||||
## 3. Re[[Solution|Solution]] (해결책)
|
||||
탄환 객체의 기본 데미지 필드(`bullet.dmg`)를 로컬 변수 `damage`에 명시적으로 할당하여 스코프 내 가용성을 확보함.
|
||||
|
||||
## 4. Anti-Recurrence (방지 전략)
|
||||
1. **Lint Rules**: `no-undef` 규칙을 프로젝트 설정에 강제하여 빌드 시점에 차단.
|
||||
2. **Review Filter**: 대규모 로직 교환 시, 변수의 로컬 선언 여부를 필수 체크 리스트에 등재.
|
||||
3. **Automated [[Testing|Testing]]**: 교전 시나리오에 대한 단위 테스트(Unit Test)를 통해 문법적 결함 사전 발견.
|
||||
|
||||
---
|
||||
**Status**: Case Closed
|
||||
**Type**: Syntax Inte[[Grit|Grit]]y / Troubleshooting
|
||||
Reference in New Issue
Block a user