refactor(topics): 멀티 에이전트용 지식 재편 — _Common(공통 기본기) + Domain_* 구조
에이전트 8종(대화형/프로그래머 C·S/디자이너/설계자/기획자/QA/PD/PM)에게 [공통 기본 능력 + 롤별 Specialty] 2층으로 지식을 주입하기 위한 재분류. 문서 내용·포맷은 무수정, 폴더 이동만 (6,372개 문서 수 보존 확인). - Topic_Programming → Domain_Programming (내부 구조 보존) - Topic_Graphic → Domain_Design - Topic_Business → Domain_Product - Topic_General → Domain_General - _Common 신설: Math(구 Topic_Math_Specialty), Reasoning(구 General/From_Thinking & Reasoning), Reasoning_Creativity(구 General/From_창의성), Communication(Poetic_Blog_Writing + From_writing) - 타 도메인의 From_* 폴더는 유지 (출처 표기일 뿐, 이미 도메인에 맞게 분류된 문서) - 빈 폴더 정리 (memory/procedures) - 에이전트→폴더 매핑은 workspace의 .astra/agent-knowledge-map.json (9개 에이전트) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Antigravity Agent
+27
@@ -0,0 +1,27 @@
|
||||
# Engine Stability and 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
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Optimization]]
|
||||
+39
@@ -0,0 +1,39 @@
|
||||
# Skybound Implementation and 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 Feedback System
|
||||
유저의 시각적/촉각적 몰입을 극대화하기 위한 연출 가이드입니다.
|
||||
- **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 개발부장 '코다리'
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Architecture]]
|
||||
* [[Dopamine]]
|
||||
* [[_report]]
|
||||
* [[_system]]
|
||||
+51
@@ -0,0 +1,51 @@
|
||||
# [TECH-REPORT] Skybound Boss Battle Architecture (v1.0)
|
||||
**Date**: 2026-04-22
|
||||
**Author**: Antigravity (Dev Lead)
|
||||
**Status**: COMPLETED / STABLE
|
||||
|
||||
## 1. 개요 (Overview)
|
||||
Skybound Protocol의 8단계 캠페인 시스템 완성을 위한 '데이터 주도형 보스 전투 시스템'의 구현 상세를 기록한다. 본 시스템은 하드코딩된 보스 로직을 탈피하고, 외부 레지스트리 기반의 페이즈 제어 및 플레이어 숙련도(Mastery)에 따른 최종 보스 분기 로직을 핵심으로 한다.
|
||||
|
||||
## 2. 주요 구현 사항 (Key Implementations)
|
||||
|
||||
### 2.1 기체별 데미지 감쇄 시스템 (Damage Mitigation)
|
||||
- **목적**: 기체(Airframe)별 개성을 강화하고 생존 전략의 차별화 제공.
|
||||
- **로직**: `CombatSystem.ts` 내 피격 판정 시 `GAME_BALANCE`의 감쇄율 적용.
|
||||
- **수치**:
|
||||
- **FALCON**: 탄환 -17% / 충돌 -34%
|
||||
- **RAYCE**: 탄환 -13% / 충돌 -26%
|
||||
|
||||
### 2.2 보스 레지스트리 아키텍처 (Boss Registry)
|
||||
- **파일**: `src/features/game/config/bossRegistry.ts`
|
||||
- **역할**: 스테이지별 보스 데이터(이름, ID, 페이즈 구성, 패턴 밀도)의 Single Source of Truth.
|
||||
- **특징**: `resolveNextPhase()` 유틸리티를 통해 HP 임계값, 부하 기체 전멸(`MINIONS_CLEARED`), 부품 파괴 등 다양한 조건에 따른 동적 페이즈 전환 지원.
|
||||
|
||||
### 2.3 최종 보스 분기 로직 (Mastery Branching)
|
||||
- **위치**: `StageDirectorSystem.ts` -> `instantiateBoss()`
|
||||
- **조건**: 인게임 모든 업그레이드(6종)가 **Level 10 (Mastery)**에 도달했는지 체크.
|
||||
- **분기**:
|
||||
- **Normal**: 험프티 덤프티 (Humpty Dumpty)
|
||||
- **Mastery**: 디바인 램파트 (Divine Rampart) - 기본 체력 1.5배 증가 및 4단계 페이즈 구성.
|
||||
|
||||
## 3. 데이터 구조 (Data Structure)
|
||||
|
||||
```typescript
|
||||
export interface BossPhase {
|
||||
phaseIndex: number;
|
||||
attackPatterns: Pattern[];
|
||||
transformationTrigger: 'HP_THRESHOLD' | 'ALL_PARTS_DESTROYED' | 'MINIONS_CLEARED' | null;
|
||||
hpThreshold: number | null;
|
||||
}
|
||||
```
|
||||
|
||||
## 4. 향후 유지보수 가이드 (Maintenance)
|
||||
- **보스 추가**: `bossRegistry.ts`의 `BOSS_REGISTRY` 배열에 신규 `BossDefinition`을 추가하는 것만으로 신규 보스 및 페이즈 설계 가능.
|
||||
- **밸런스 조정**: `balance.ts`의 `PLAYER.AIRFRAMES` 섹션에서 감쇄율 수치 즉시 조정 가능.
|
||||
|
||||
---
|
||||
**Approval Status**: 🫡 (Kodari Approved)
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Architecture]]
|
||||
* [[Single_Source_of_Truth]]
|
||||
@@ -0,0 +1,34 @@
|
||||
# 📝 [Technical Report] 보스 스폰 시스템 안정화 및 AI 교전 로직 개선
|
||||
|
||||
## 1. 개요 (Overview)
|
||||
본 문서는 Skybound 프로젝트의 최종 보스 미출현 이슈 해결 및 적기 AI의 공격성 강화를 위한 기술적 수정 사항을 기록합니다.
|
||||
|
||||
## 2. 적기 AI 개선 (Enemy AI Overhaul)
|
||||
기존의 '낙엽 효과(Wobble)'와 '회피(Avoidance)' 로직을 제거하고 공격적 교전 패턴을 도입했습니다.
|
||||
|
||||
- **낙엽 효과 제거**: `CombatSystem` 내 `Math.sin` 기반 좌우 흔들림 로직 삭제.
|
||||
- **회피 로직 삭제**: 플레이어 근접 시 발생하는 기피력(Repulsion) 제거.
|
||||
- **예측 요격(Predictive Interception)**: 플레이어의 현재 속도($v_x, v_y$)를 기반으로 12프레임 뒤의 위치를 타격하는 로직 적용.
|
||||
- **근접전 페널티**: 플레이어와 거리 250px 이내에서 연사력 2배 부스트 적용.
|
||||
|
||||
## 3. 보스 스폰 안정화 (Boss Spawn Fix)
|
||||
트리거와 페이즈 전환 간의 동기화 오류를 해결했습니다.
|
||||
|
||||
- **트리거 선행 배치**: `CombatTimeline`의 보스 스폰 트리거를 페이즈 시작 10초 전으로 앞당김 (870s -> 860s).
|
||||
- **시퀀스 가속**:
|
||||
- `FINAL_BOSS` -> `BOSS_WARNING`: 180프레임 -> 60프레임 (1초)
|
||||
- `BOSS_WARNING` -> `BOSS`: 300프레임 -> 120프레임 (2초)
|
||||
- **응답성 개선**: 보스 경고 발생 후 실제 등장까지의 체감 대기 시간을 총 8초에서 3초로 단축.
|
||||
|
||||
## 4. 엔진 무결성 점검 (Integrity Check)
|
||||
- `StageDirectorSystem.ts`의 코드 단절(Truncation) 여부를 확인하고 정상 작동을 검증함.
|
||||
- `CombatSystem.ts`의 타입 안전성 확보 및 AI 역할별 이동 패턴 정상화 확인.
|
||||
|
||||
---
|
||||
**Status**: Green (Operational)
|
||||
**Author**: Antigravity (AI Dev Director 'Kodari')
|
||||
**Date**: 2026-04-22
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[_report]]
|
||||
@@ -0,0 +1,34 @@
|
||||
# ISSUE REPORT: [v13.1] Engine Stabilization & Tactical Boundary Overhaul
|
||||
|
||||
## 1. 개요
|
||||
Skybound 엔진의 초기 구동 안정성을 확보하고, 게임의 장르적 성향(전략 슈터)을 강화하기 위한 적기 이동 로직 및 레벨업 시스템의 결함을 해결함.
|
||||
|
||||
## 2. 해결된 결함 (Level-Up Loop)
|
||||
### 2.1 현상
|
||||
- 게임 시작 직후 `TAC LEVEL UP` 모달이 무한 반복 출력되어 조작 불능 상태 발생.
|
||||
- 엔진 내부 레벨과 Zustand 스토어 레벨 간의 동기화 불일치.
|
||||
|
||||
### 2.2 원인 분석
|
||||
- `StageDirectorSystem`: 타임라인 이벤트가 최소 시간 가드 없이 초기화 시점에 조기 발동.
|
||||
- `ProgressionSystem`: 스킬 선택 시 Zustand 구독과 엔진 로직 양쪽에서 레벨을 이중 증가시킴.
|
||||
|
||||
### 2.3 수정 사항
|
||||
- **StageDirectorSystem**: 15초/30초 최소 시간 가드 및 `processed[[Events|Events]]econds` 중복 발동 방지 락 도입.
|
||||
- **ProgressionSystem**: 이중 증가 로직 제거 및 Zustand [[Single_Source_of_Truth|Single Source of Truth]](SSOT) 강화.
|
||||
- **UI**: `LevelUpModal`에 `isChest` 플래그를 추가하여 일반 레벨업과 보급품(Supply Drop) 보상을 시각적으로 분리.
|
||||
|
||||
## 3. 기능 개선 (Enemy Tactical Boundary)
|
||||
### 3.1 현상
|
||||
- 적기가 격파되지 않은 상태에서 화면 하단으로 유유히 사라짐 (전통적 슈팅 게임 방식).
|
||||
- 플레이어의 전략적 대응 영역 및 경험치 수급 기회 상실.
|
||||
|
||||
### 3.2 수정 사항 (CombatSystem)
|
||||
- **Boundary Clamp**: 적기의 이동 허용 범위를 `height + 300`에서 `height - 40`으로 타이트하게 조정.
|
||||
- **Chase Pattern**: 플레이어 추격 시 화면 하단 경계를 인식하도록 가드 추가.
|
||||
- **Zigzag Pattern**: 화면 하단 도달 시 방향을 반전시키는 '핑퐁(Ping-pong)' 패턴으로 업그레이드.
|
||||
- **Striker AI**: 하단 돌진 후 상단으로 복귀하는 순찰 로직 추가.
|
||||
|
||||
## 4. 기대 효과
|
||||
- **안정성**: 게임 초기화 및 재개 시 발생하는 상태 데드락 원천 차단.
|
||||
- **전략성**: 모든 적이 화면 내에 유지됨으로써 플레이어의 통제권 강화 및 생존 슈터로서의 긴장감 극대화.
|
||||
- **경제**: 경험치 젬 및 루트 아이템의 화면 밖 유실 방지.
|
||||
@@ -0,0 +1,34 @@
|
||||
# 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의 **'전술적 긴장감'**과 **'성장 루프'**가 정상 궤도에 진입함. 보스전 - 보급 - 스테이지 전환으로 이어지는 핵심 게임 루프의 기술적 무결성 확인 완료. 🫡🐟
|
||||
+141
@@ -0,0 +1,141 @@
|
||||
# Skybound Code Structure Audit and Stabilization Plan
|
||||
|
||||
**Date**: 2026-04-24
|
||||
**Project**: Skybound Protocol
|
||||
**Author**: Codex
|
||||
**Status**: Raw analysis logged before implementation
|
||||
|
||||
## 1. Overview
|
||||
|
||||
This document records the first code-level audit after reviewing Skybound-related wiki documents. The goal was to compare the documented architecture with the actual code path in `/Volumes/Data/project/Antigravity/Skybound`, identify design and feature risks, and define the first stabilization pass.
|
||||
|
||||
## 2. Documents Reviewed
|
||||
|
||||
- `Topics/Skybound/Skybound-Knowledge-Hub.md`
|
||||
- `Topics/Skybound/01_Core_Engine/Skybound-Modular-Game-Architecture.md`
|
||||
- `Topics/Skybound/01_Core_Engine/Game-Engine-Loop-and-System-Orchestration.md`
|
||||
- `Topics/Skybound/05_Project_Issues/2026-04-22_Engine_Stability_Audit.md`
|
||||
- `Topics/Skybound/02_Combat_AI/Combat-System-and-Bullet-Interaction-Pipeline.md`
|
||||
- `Topics/Skybound/04_Mechanics_Progression/Campaign_and_Dual_Loop_System.md`
|
||||
- `Topics/Skybound/04_Mechanics_Progression/InGame_Progression_System.md`
|
||||
- `Technical_Reports/2026-04-22_Boss_Battle_System_Implementation.md`
|
||||
|
||||
## 3. Code Structure Observations
|
||||
|
||||
Skybound's actual runtime center is `src/features/game/hooks/useGameEngine.ts`. It directly instantiates and updates `EntityManager`, `StageDirectorSystem`, `SpawnerSystem`, `CombatSystem`, `ProgressionSystem`, `ModularWeaponSystem`, `TacticalSystem`, `HazardSystem`, `BossSystem`, `EffectSystem`, and `GameRenderer`.
|
||||
|
||||
`SystemManager.ts` exists and documents a centralized orchestration pattern, but the active engine path does not use it. This is not inherently broken, but it creates a mismatch between the documented orchestrator and the actual execution path.
|
||||
|
||||
React is primarily responsible for scene composition and modal/UI handling through `GameSceneRenderer.tsx`, while Zustand state is centralized in `useGameStore.ts`.
|
||||
|
||||
## 4. Confirmed Problems
|
||||
|
||||
### 4.1 Build Gate Is Broken
|
||||
|
||||
`npm run build` fails. Representative causes:
|
||||
|
||||
- `App.tsx` imports `useGameEngine` but does not use it.
|
||||
- Legacy `src/features/game/combatSystem.ts` is still included in TypeScript compilation and has type drift against current domain models.
|
||||
- `useSceneAudio.ts` does not include `HANGAR` in `SCENE_AUDIO`, despite `Scene` including `HANGAR`.
|
||||
- `SystemBoss.phase` is typed as `1 | 2 | 3`, while `bossRegistry.ts` contains a 4-phase boss.
|
||||
- `GameRenderer.ts` calls `CanvasRenderingContext2D.close()`, which should be `closePath()`.
|
||||
- `EntityManager` initializes enemies with `movePattern: 'NONE'`, which is not part of the current `Enemy.movePattern` union.
|
||||
|
||||
### 4.2 Timeline Spawn Intents Are Not Wired
|
||||
|
||||
`StageDirectorSystem` dispatches `SCRIPTED_SPAWN` and `SPAWN_MODE` intents, but `useGameEngine.ts` does not route those intents to `SpawnerSystem`.
|
||||
|
||||
`SpawnerSystem` already provides `notifyScriptedSpawn()` and `activateSwarmBurst()`, so the design exists but the active dispatch wiring is missing.
|
||||
|
||||
Expected impact: scripted waves and burst events may not appear as designed, leaving procedural spawning to carry too much of the combat pacing.
|
||||
|
||||
### 4.3 Campaign Stage State Is Not a Single Source of Truth
|
||||
|
||||
`StageDirectorSystem` receives `campaignStageIndex` when created, but `GameState.currentStage` still defaults to `1` and is not initialized from the selected campaign stage.
|
||||
|
||||
Expected impact: Standard campaign can show stage progression in UI while the engine continues to evaluate boss selection, damage curves, backgrounds, rewards, and tech-part rolls as Stage 1.
|
||||
|
||||
### 4.4 StageManager Mode Can Drift from Store Mode
|
||||
|
||||
`StageManager` has its own internal `mode`, defaulting to `BLITZ`. The UI updates Zustand `stageMode`, but `stageManager.setMode()` is not called from the store action.
|
||||
|
||||
Expected impact: Standard campaign clear can call `stageManager.onStageClear()` while the singleton still believes it is in Blitz mode, preventing next-stage campaign progression.
|
||||
|
||||
### 4.5 COMMS Events Are Not Rendered
|
||||
|
||||
`COMMS` events are emitted by engine systems, and `CommsOverlay.tsx` exists, but `useGameEngine.ts` does not map `COMMS` events to `useGameStore.setComms()`. `CommsOverlay` is also not rendered by `App.tsx`.
|
||||
|
||||
Expected impact: mission dialogue, warning text, and tactical pacing messages are silently dropped.
|
||||
|
||||
### 4.6 Starter Weapon Timer Is Not Cleaned Up
|
||||
|
||||
`useGameEngine.ts` starts a `setTimeout()` for starter weapon selection, but cleanup does not clear the timer.
|
||||
|
||||
Expected impact: if the engine unmounts quickly, a stale timer can emit a level-up modal or pause signal from an old engine instance.
|
||||
|
||||
### 4.7 Skill Sync Boundary Is Fragile
|
||||
|
||||
`GameSceneRenderer.tsx` calls store `addSkill()` and then engine `applySkill()`. `ProgressionSystem.applySkillSelection()` says Zustand owns skill increments, but also mutates `state.skills` as a fallback.
|
||||
|
||||
Expected impact: this usually works because of the store subscription bridge, but the ownership boundary is not clean and may cause missed or inconsistent skill levels under timing stress.
|
||||
|
||||
## 5. Stabilization Plan
|
||||
|
||||
Priority order:
|
||||
|
||||
1. Restore TypeScript build by removing obvious compile blockers and isolating legacy drift.
|
||||
2. Wire `SCRIPTED_SPAWN` and `SPAWN_MODE` intents from `StageDirectorSystem` into `SpawnerSystem`.
|
||||
3. Initialize engine `currentStage` from `stageMode` and `campaignStageIndex`.
|
||||
4. Keep `StageManager` mode synchronized with Zustand `stageMode`.
|
||||
5. Route `COMMS` events into the store and render `CommsOverlay`.
|
||||
6. Clear the starter weapon timer during engine cleanup.
|
||||
|
||||
## 6. Verification Targets
|
||||
|
||||
- `npm run build`
|
||||
- `npm run lint` as a visibility check, with the expectation that broad historical lint debt may remain after the first stabilization pass.
|
||||
|
||||
## 7. Implementation Result
|
||||
|
||||
The first stabilization pass was applied immediately after this raw audit.
|
||||
|
||||
### 7.1 Build Recovery
|
||||
|
||||
- Removed an unused `useGameEngine` import from `App.tsx`.
|
||||
- Added `HANGAR` to `SCENE_AUDIO` in `useSceneAudio.ts`.
|
||||
- Excluded legacy `src/features/game/combatSystem.ts` from `tsconfig.app.json` because the active runtime path uses `src/features/game/systems/CombatSystem.ts`.
|
||||
- Expanded boss phase typing from `1 | 2 | 3` to `number` so 4-phase registry bosses are valid.
|
||||
- Fixed `EntityManager` default enemy `movePattern` from invalid `NONE` to `SIDE_TO_SIDE`.
|
||||
- Fixed `CanvasRenderingContext2D.close()` to `closePath()`.
|
||||
- Removed compile-blocking unused locals from active systems.
|
||||
|
||||
### 7.2 Runtime Wiring Recovery
|
||||
|
||||
- `SCRIPTED_SPAWN` intents now call `SpawnerSystem.notifyScriptedSpawn()`.
|
||||
- `SPAWN_MODE` intents now activate `SWARM_BURST` or enqueue `MINI_BOSS` spawns.
|
||||
- Engine `currentStage` now initializes from `campaignStageIndex + 1` in Standard mode.
|
||||
- Zustand `setStageMode()` now synchronizes the `StageManager` singleton mode.
|
||||
- `COMMS` engine events now populate `useGameStore.activeComms`.
|
||||
- `CommsOverlay` is rendered while playing.
|
||||
- Starter weapon selection timer is cleared during engine cleanup.
|
||||
|
||||
### 7.3 Verification Result
|
||||
|
||||
- `npm run build`: passed.
|
||||
- `npm run lint`: still fails due broad pre-existing lint debt, mostly `@typescript-eslint/no-explicit-any`, older helper files, and React hook lint findings. The first pass reduced the functional blockers but did not attempt a large-scale type cleanup.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[2026-04-22_Boss_Battle_System_Implementation]]
|
||||
* [[2026-04-22_Engine_Stability_Audit]]
|
||||
* [[Analysis]]
|
||||
* [[Architecture]]
|
||||
* [[Campaign_and_Dual_Loop_System]]
|
||||
* [[Combat-System-and-Bullet-Interaction-Pipeline]]
|
||||
* [[ESLint]]
|
||||
* [[Events]]
|
||||
* [[React]]
|
||||
* [[Single_Source_of_Truth]]
|
||||
* [[Skybound-Knowledge-Hub]]
|
||||
* [[State]]
|
||||
* [[goal]]
|
||||
+156
@@ -0,0 +1,156 @@
|
||||
# Skybound Final Stylized Casual Magitech Redirection
|
||||
|
||||
**Date**: 2026-04-24
|
||||
**Project**: Skybound Protocol
|
||||
**Author**: Codex
|
||||
**Status**: Raw art direction correction after final concept change
|
||||
|
||||
## 1. Reason for Redirection
|
||||
|
||||
The previous pass moved Skybound toward **Semirealistic Magitech Fantasy**, but the latest direction returns the project to a clearer and more immediately readable mobile-survival style.
|
||||
|
||||
The new target is **Stylized Casual Magitech** for a top-down survival shooter inspired by Survivor.io.
|
||||
|
||||
This direction prioritizes:
|
||||
|
||||
- maximum in-game visibility
|
||||
- bold silhouettes
|
||||
- thick readable outlines
|
||||
- flat lighting
|
||||
- vivid magical accents
|
||||
- consistent UI language from intro to mission result
|
||||
|
||||
## 2. Core Concept
|
||||
|
||||
Skybound should feel like a polished casual magitech action game rather than a dark semirealistic fantasy title.
|
||||
|
||||
Primary gameplay readability goals:
|
||||
|
||||
- player vehicle must be instantly identifiable
|
||||
- enemies must remain readable in dense hordes
|
||||
- pickups and weapon icons must be recognizable at small sizes
|
||||
- background grid must support movement clarity without competing with combat
|
||||
- every exposed screen should share the same playful magitech frame language
|
||||
|
||||
## 3. Tone and Manner
|
||||
|
||||
### Stylized Casual Magitech
|
||||
|
||||
Visual language:
|
||||
|
||||
- bold navy outlines
|
||||
- clean top-down silhouettes
|
||||
- flat color blocks
|
||||
- minimal material noise
|
||||
- bright arcane cyan
|
||||
- gold/orange mechanical accents
|
||||
- purple and pink enemy/corruption accents
|
||||
- chunky UI frames
|
||||
- high contrast buttons and progress bars
|
||||
|
||||
Avoid:
|
||||
|
||||
- gritty brushed metal
|
||||
- heavy realistic shadows
|
||||
- low-contrast dark UI
|
||||
- thin semireal linework
|
||||
- noisy texture detail
|
||||
- external non-project image dependencies
|
||||
|
||||
## 4. Palette
|
||||
|
||||
Base colors:
|
||||
|
||||
- deep navy outline
|
||||
- saturated royal blue panels
|
||||
- readable sapphire floor tiles
|
||||
- bright brass and gold trim
|
||||
|
||||
Magic accents:
|
||||
|
||||
- arcane cyan for player and positive energy
|
||||
- crystal white-blue for highlights
|
||||
- vivid purple for advanced magic
|
||||
- hot pink for danger and enemy cores
|
||||
- mint green for healing and positive pickups
|
||||
- orange/gold for calls to action
|
||||
|
||||
## 5. Screen Coverage
|
||||
|
||||
The exposed user-facing screens were reviewed and targeted by the final theme pass:
|
||||
|
||||
- Intro title screen
|
||||
- Airframe select screen
|
||||
- Hangar / upgrade overlay
|
||||
- In-game HUD
|
||||
- Quick start overlay
|
||||
- Tutorial overlay
|
||||
- Comms overlay
|
||||
- Level up modal
|
||||
- Mission success / failed / complete result screen
|
||||
|
||||
## 6. Asset Coverage
|
||||
|
||||
The procedural asset generator now outputs the final Stylized Casual Magitech library while preserving runtime file paths.
|
||||
|
||||
Generated categories:
|
||||
|
||||
- Magitech player airframes
|
||||
- normal enemies
|
||||
- elite enemies
|
||||
- bosses
|
||||
- modular stage tiles
|
||||
- title and result local backdrops
|
||||
- item drop sprite sheet
|
||||
- turret sheet
|
||||
- weapon and skill icons
|
||||
- projectiles
|
||||
- shield and currency icons
|
||||
- muzzle flash, impact, explosion, and laser VFX
|
||||
- commander and pilot portraits
|
||||
- contact sheet preview
|
||||
|
||||
## 7. Implementation Notes
|
||||
|
||||
The generator was redirected away from semirealistic material rendering and toward flat, readable shapes.
|
||||
|
||||
Main implementation choices:
|
||||
|
||||
- palette updated to bright casual magitech colors
|
||||
- default shape helpers now draw bold navy outlines
|
||||
- material texture strength reduced to keep assets flat
|
||||
- background tiles use readable grid blocks and low-competition arcane circuitry
|
||||
- local title and result background images were generated
|
||||
- title and result screens no longer depend on external Google image URLs
|
||||
- global magitech CSS override was rewritten for the final casual tone
|
||||
|
||||
## 8. Changed Runtime Paths
|
||||
|
||||
Important changed or generated paths:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/scripts/generate_magitech_assets.py`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/styles/magitechArt.css`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/TitleScreen.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/ResultCard.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/public/sprites/magitech_art_contact_sheet.png`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/public/sprites/background/title_magitech.png`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/public/sprites/background/result_magitech.png`
|
||||
|
||||
## 9. Verification
|
||||
|
||||
Asset generation completed successfully.
|
||||
|
||||
Production build completed successfully with:
|
||||
|
||||
```bash
|
||||
npm run build
|
||||
```
|
||||
|
||||
The build still reports that `/sprites/player.png` is left unresolved at build time, which is a Vite static asset warning and was already non-blocking. The production bundle was generated successfully.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Metal]]
|
||||
* [[Noise]]
|
||||
* [[Reports]]
|
||||
* [[Scripts]]
|
||||
+78
@@ -0,0 +1,78 @@
|
||||
# Skybound HUD and TAC Level Up Stylized Casual Magitech Fix
|
||||
|
||||
**Date**: 2026-04-24
|
||||
**Project**: Skybound Protocol
|
||||
**Author**: Codex
|
||||
**Status**: Raw follow-up fix from gameplay HUD screenshot review
|
||||
|
||||
## 1. Screenshot Issues
|
||||
|
||||
The reviewed gameplay screenshots showed that the HUD and TAC Level Up modal still leaned heavily into the previous cyber-terminal style.
|
||||
|
||||
Observed issues:
|
||||
|
||||
- side HUD panels used thin cyan lines and transparent glass styling
|
||||
- top TAC level widget looked like a cold terminal module
|
||||
- control buttons were dark monochrome blocks
|
||||
- TAC Level Up modal used glitch text and blue terminal cards
|
||||
- skill cards did not share the bold casual magitech frame language
|
||||
|
||||
## 2. Cause
|
||||
|
||||
The global `magitechArt.css` provided the broad art direction, but component-level CSS files still applied later or more specific styles.
|
||||
|
||||
Main affected files:
|
||||
|
||||
- `HUDOverlay.css`
|
||||
- `LevelUpModal.css`
|
||||
|
||||
These files preserved the original Stitch/cyber UI look and overrode parts of the new tone.
|
||||
|
||||
## 3. Fixes Applied
|
||||
|
||||
### HUD
|
||||
|
||||
HUD styling was redirected to Stylized Casual Magitech:
|
||||
|
||||
- chunky navy outlines
|
||||
- rounded blue magitech panels
|
||||
- gold active highlights
|
||||
- mint/cyan resource bars
|
||||
- less transparent glass
|
||||
- stronger mobile-game button affordance
|
||||
- side modules grouped into readable cards
|
||||
- top TAC level widget converted to a framed casual panel
|
||||
|
||||
### TAC Level Up Modal
|
||||
|
||||
The level-up modal was restyled:
|
||||
|
||||
- removed glitch pseudo text
|
||||
- removed aggressive terminal skew animation
|
||||
- converted the modal into a rounded blue magitech reward panel
|
||||
- added thick dark outline and drop-shadow depth
|
||||
- changed skill cards to chunky selectable cards
|
||||
- changed icon boxes to framed magitech sockets
|
||||
- converted level dots into brighter readable pips
|
||||
- kept EVO cards gold/orange for special hierarchy
|
||||
|
||||
## 4. Changed Runtime Paths
|
||||
|
||||
Important changed paths:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/HUDOverlay.css`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/LevelUpModal.css`
|
||||
|
||||
## 5. Verification
|
||||
|
||||
Production build completed successfully with:
|
||||
|
||||
```bash
|
||||
npm run build
|
||||
```
|
||||
|
||||
The existing `/sprites/player.png` static path warning remains non-blocking.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Affordance]]
|
||||
+87
@@ -0,0 +1,87 @@
|
||||
# Skybound Nova Burst Icon and Effect Fix
|
||||
|
||||
**Date**: 2026-04-24
|
||||
**Project**: Skybound Protocol
|
||||
**Author**: Codex
|
||||
**Status**: Raw follow-up fix for skill-specific visual mismatch
|
||||
|
||||
## 1. Screenshot Issue
|
||||
|
||||
`Nova Burst` looked like a lemon-shaped projectile icon.
|
||||
|
||||
This did not match the actual skill behavior.
|
||||
|
||||
## 2. Skill Meaning
|
||||
|
||||
`Nova Burst` is not a missile, crystal shard, or thrown projectile.
|
||||
|
||||
Actual gameplay behavior:
|
||||
|
||||
- automatic radial AoE shockwave
|
||||
- triggers around the player
|
||||
- damages enemies inside the radius
|
||||
- knocks enemies outward
|
||||
- cooldown-based burst every few seconds
|
||||
- evolves into `Nova Guardian`, which adds stronger golden guardian behavior
|
||||
|
||||
## 3. Art Direction Correction
|
||||
|
||||
The icon should communicate:
|
||||
|
||||
- central arcane core
|
||||
- circular shockwave expansion
|
||||
- radial force
|
||||
- rune-like magitech energy
|
||||
- area control around the player
|
||||
|
||||
It should not communicate:
|
||||
|
||||
- lemon
|
||||
- fruit
|
||||
- single projectile
|
||||
- gem pickup
|
||||
- missile tip
|
||||
|
||||
## 4. Fixes Applied
|
||||
|
||||
The procedural generator now creates `Nova Burst.png` with a dedicated `nova` icon shape.
|
||||
|
||||
New visual structure:
|
||||
|
||||
- cyan circular shockwave rings
|
||||
- central navy magitech core
|
||||
- arcane core light
|
||||
- radial spokes showing outward force
|
||||
- subtle purple secondary energy ring
|
||||
|
||||
The in-game Nova Burst renderer was also adjusted:
|
||||
|
||||
- center sprite is smaller and treated as a rune core
|
||||
- expanding shockwave ring is now the main visual read
|
||||
- added translucent pressure disk
|
||||
- added segmented rune ring
|
||||
- kept Guardian variant as gold/orange
|
||||
|
||||
## 5. Changed Runtime Paths
|
||||
|
||||
Important changed paths:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/scripts/generate_magitech_assets.py`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/GameRenderer.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/public/sprites/missiles/Nova Burst.png`
|
||||
|
||||
## 6. Verification
|
||||
|
||||
Asset generation completed successfully.
|
||||
|
||||
Production build completed successfully with:
|
||||
|
||||
```bash
|
||||
npm run build
|
||||
```
|
||||
|
||||
The existing `/sprites/player.png` static asset warning remains non-blocking.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Scripts]]
|
||||
+78
@@ -0,0 +1,78 @@
|
||||
# Skybound Particle and Supply Readability Fix
|
||||
|
||||
**Date**: 2026-04-24
|
||||
**Project**: Skybound Protocol
|
||||
**Author**: Codex
|
||||
**Status**: Raw follow-up fix from gameplay screenshot review
|
||||
|
||||
## 1. Screenshot Issues
|
||||
|
||||
The reviewed screenshot exposed two readability problems.
|
||||
|
||||
Observed issues:
|
||||
|
||||
- Mint/cyan square particles were scattered across the floor and looked like items even though they could not be collected.
|
||||
- The supply crate asset looked good, but it was not clear whether it was a player pickup or an enemy projectile/debris object.
|
||||
|
||||
## 2. Cause
|
||||
|
||||
### Mint Floor Squares
|
||||
|
||||
The mint squares were runtime particles from `EffectSystem`.
|
||||
|
||||
They were rendered in `GameRenderer.renderEffects()` using `fillRect()`, so every spark appeared as a small collectible-looking square.
|
||||
|
||||
These particles can come from combat hits, skill effects, EMP interactions, exp pickup feedback, or other short-lived feedback systems.
|
||||
|
||||
### Supply Ambiguity
|
||||
|
||||
The supply crate sprite itself was readable as an object, but the gameplay affordance was weak.
|
||||
|
||||
It needed explicit pickup language:
|
||||
|
||||
- pickup color
|
||||
- capture ring
|
||||
- directional marker
|
||||
- short label
|
||||
|
||||
## 3. Fixes Applied
|
||||
|
||||
### Particle Shape
|
||||
|
||||
Runtime particles now render as small rotated diamond sparks instead of square floor blocks.
|
||||
|
||||
This keeps the magical spark feedback while reducing item confusion.
|
||||
|
||||
Normal shard fragments were also changed from square blocks to triangular fragments.
|
||||
|
||||
### Supply Pickup Readability
|
||||
|
||||
Supply drops now render with:
|
||||
|
||||
- mint-green dashed pickup ring
|
||||
- soft pickup fill
|
||||
- bobbing downward arrow
|
||||
- retained supply crate sprite
|
||||
- `PICK UP` label
|
||||
|
||||
This separates supply drops from enemy bullets, hazards, and cosmetic particles.
|
||||
|
||||
## 4. Changed Runtime Paths
|
||||
|
||||
Important changed path:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/GameRenderer.ts`
|
||||
|
||||
## 5. Verification
|
||||
|
||||
Production build completed successfully with:
|
||||
|
||||
```bash
|
||||
npm run build
|
||||
```
|
||||
|
||||
The existing `/sprites/player.png` static path warning remains non-blocking.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Affordance]]
|
||||
+145
@@ -0,0 +1,145 @@
|
||||
# Skybound Semirealistic Magitech Fantasy Redirection
|
||||
|
||||
**Date**: 2026-04-24
|
||||
**Project**: Skybound Protocol
|
||||
**Author**: Codex
|
||||
**Status**: Raw art direction correction before second asset pass
|
||||
|
||||
## 1. Reason for Redirection
|
||||
|
||||
The first generated art pack leaned too far into childish cartoon readability: thick outlines, flat toy-like shapes, and simplified symbolic silhouettes.
|
||||
|
||||
The new target is **Semirealistic Magitech Fantasy** for a top-down horde survival-shmup inspired by Survivor.io, aimed at players aged 12-18 and casual adults.
|
||||
|
||||
## 2. Core Concept
|
||||
|
||||
The visual library should feel detailed, grounded, and cool rather than cute.
|
||||
|
||||
Primary references by feel:
|
||||
|
||||
- League of Legends-like readable fantasy detail
|
||||
- Warhammer-like dark material weight
|
||||
- Survivor.io-like top-down clarity and grid readability
|
||||
|
||||
This is still a game with high enemy density, so readability remains critical, but contrast should come from lighting, value, and energy color rather than thick black outlines.
|
||||
|
||||
## 3. Tone and Manner
|
||||
|
||||
### Semirealistic Magitech
|
||||
|
||||
Visual language:
|
||||
|
||||
- dark iron
|
||||
- aged brass
|
||||
- brushed metal
|
||||
- weathered stone
|
||||
- glowing crystals
|
||||
- engraved runes
|
||||
- arcane circuitry
|
||||
- controlled deep shadows
|
||||
- focused magical highlights
|
||||
|
||||
Avoid:
|
||||
|
||||
- childish cartoon shapes
|
||||
- toy-like flat icons
|
||||
- heavy black outlines
|
||||
- overly bright candy palettes
|
||||
- large simplified emblem-only designs
|
||||
|
||||
## 4. Palette
|
||||
|
||||
Base colors:
|
||||
|
||||
- dark sapphire
|
||||
- dark iron
|
||||
- forest green
|
||||
- weathered brass
|
||||
- basalt gray
|
||||
- deep crimson
|
||||
|
||||
Magic accents:
|
||||
|
||||
- arcane blue for player energy
|
||||
- neon purple for corruption
|
||||
- plasma red for enemy/boss danger
|
||||
- molten orange for forge/lava accents
|
||||
|
||||
## 5. Asset Rules
|
||||
|
||||
### Player Vehicle
|
||||
|
||||
The player vehicle should read as a Magitech airship rather than a simple airplane.
|
||||
|
||||
Required traits:
|
||||
|
||||
- complex symmetrical or slightly asymmetrical hull
|
||||
- dark iron and brass material mix
|
||||
- intense crystalline power core
|
||||
- smaller gun turrets
|
||||
- visible engine components, gears, vents, and rune plates
|
||||
- subtle energy glow readable from top-down view
|
||||
|
||||
### Enemies
|
||||
|
||||
Enemies should be threatening corrupted creatures or ancient mechanical horrors.
|
||||
|
||||
Examples:
|
||||
|
||||
- clockwork spiders with poison sacks
|
||||
- rune golems made of dark stone
|
||||
- corrupted winged drakes
|
||||
- ancient mechanical horrors with plasma-red cores
|
||||
|
||||
### Background
|
||||
|
||||
Background should preserve Survivor.io-style grid readability but feel like an immersive fantasy environment.
|
||||
|
||||
Target environments:
|
||||
|
||||
- ancient overgrown Magitech city ruin
|
||||
- subterranean magma forge
|
||||
|
||||
Rules:
|
||||
|
||||
- weathered stone pavement
|
||||
- broken magitech circuitry embedded in the floor
|
||||
- basalt structures
|
||||
- subtle lava or arcane channels
|
||||
- background contrast lower than enemies and player
|
||||
|
||||
### Effects
|
||||
|
||||
Player effects should be arcane blue or crystal cyan.
|
||||
|
||||
Enemy effects should lean plasma red, purple, or corrupted crimson.
|
||||
|
||||
Death effects should be optimized and satisfying:
|
||||
|
||||
- scrap metal shards
|
||||
- dark crystal fragments
|
||||
- arcane dust
|
||||
- controlled flashes, not full-screen clutter
|
||||
|
||||
### UI
|
||||
|
||||
UI should use Survivor.io-like directness with a refined dark iron and crystal shell.
|
||||
|
||||
Required traits:
|
||||
|
||||
- heavy dark iron frames
|
||||
- crystal level bar
|
||||
- rune and gear details
|
||||
- minimal but detailed HUD
|
||||
- clean modern gothic / steampunk-inspired readability
|
||||
|
||||
## 6. Implementation Notes
|
||||
|
||||
The next pass should replace the first cartoony art pack with a darker semirealistic procedural raster set while preserving runtime file paths.
|
||||
|
||||
The existing generator should be rewritten so future iterations can adjust palette, materials, and silhouettes consistently.
|
||||
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Metal]]
|
||||
+161
@@ -0,0 +1,161 @@
|
||||
# Skybound Semirealistic Magitech Fantasy Art Pack
|
||||
|
||||
**Date**: 2026-04-24
|
||||
**Project**: Skybound Protocol
|
||||
**Author**: Codex
|
||||
**Status**: Superseded by semirealistic second pass
|
||||
|
||||
## 1. Direction
|
||||
|
||||
Skybound's 2D visual identity was first redirected toward **Stylized Casual Magitech**, then corrected into **Semirealistic Magitech Fantasy** after visual review.
|
||||
|
||||
The corrected target tone is a top-down survival shooter inspired by clear mobile action readability, but with more mature fantasy material treatment:
|
||||
|
||||
- reduced outlines
|
||||
- dark iron and brass material language
|
||||
- controlled lighting
|
||||
- glowing crystalline cores
|
||||
- corrupted magical enemies
|
||||
- ancient magitech ruin backgrounds
|
||||
- high contrast at small gameplay sizes
|
||||
- color-coded enemy and weapon readability
|
||||
- playful magitech forms instead of realistic military hardware
|
||||
|
||||
## 2. Core Art Rules
|
||||
|
||||
### Silhouette
|
||||
|
||||
Every gameplay object must remain readable at 36-72px on canvas.
|
||||
|
||||
- Player vehicles use triangular forward-facing silhouettes.
|
||||
- Normal enemies use compact diamond/bug-like silhouettes.
|
||||
- Elite enemies use wider, more decorated silhouettes.
|
||||
- Bosses use tall central hulls with visible side modules and glowing cores.
|
||||
- Weapons and drops use symbolic icons instead of detailed illustrations.
|
||||
|
||||
### Linework
|
||||
|
||||
Use value contrast and glow separation instead of heavy cartoon outlines.
|
||||
|
||||
Purpose:
|
||||
|
||||
- separates sprites from busy scrolling backgrounds through lighting
|
||||
- keeps bullets, drops, and enemies visible during VFX-heavy combat
|
||||
- supports a grounded semirealistic style
|
||||
|
||||
### Lighting
|
||||
|
||||
Lighting is controlled and directional. Avoid noisy photorealism, but use subtle brushed metal, stone, and crystal texture.
|
||||
|
||||
Allowed:
|
||||
|
||||
- small inner highlights
|
||||
- soft magical glow behind important objects
|
||||
- subtle bevels
|
||||
- material grain
|
||||
- controlled shadow
|
||||
|
||||
Avoid:
|
||||
|
||||
- toy-like flat panels
|
||||
- low-contrast smoke
|
||||
- tiny greeble details
|
||||
|
||||
### Palette
|
||||
|
||||
Corrected palette:
|
||||
|
||||
- Void: `#080a12`
|
||||
- Dark iron: `#1c2029`
|
||||
- Aged brass: `#a57a37`
|
||||
- Dark sapphire: `#102a52`
|
||||
- Forest green: `#164535`
|
||||
- Crimson: `#671a20`
|
||||
- Arcane blue: `#36cdff`
|
||||
- Neon purple: `#b03eff`
|
||||
- Plasma red: `#ff4149`
|
||||
- Molten orange: `#ff7a21`
|
||||
|
||||
## 3. Generated Asset Coverage
|
||||
|
||||
The following runtime assets were regenerated in-place under `public/sprites`:
|
||||
|
||||
- player airframes: `Falcon.png`, `rayce.png`
|
||||
- charge shot: `chargeshot.png`
|
||||
- normal enemies: `normal_enemy/enemy01.png` through `enemy09.png`
|
||||
- elite enemies: `elite_enemy/elite01.png` through `elite16.png`
|
||||
- bosses: `boss/tile000.png` through `tile010.png`
|
||||
- turret atlas: `turret/turret_sprites.png`
|
||||
- item drops: `item_drops_sprite.png`
|
||||
- stage backgrounds: `background/stage_tile_1.png` through `stage_tile_8.png`
|
||||
- weapon and skill icons under `sprites/missiles`
|
||||
- core bullet, shield, currency, VFX sprites
|
||||
- comms portraits: `portraits/hq_commander.png`, `portraits/pilot_standard.png`
|
||||
|
||||
## 4. UI Skin Coverage
|
||||
|
||||
The UI skin was added through:
|
||||
|
||||
- `src/features/game/styles/magitechArt.css`
|
||||
- imported from `src/App.css`
|
||||
|
||||
The skin aligns:
|
||||
|
||||
- HUD panels
|
||||
- level-up cards
|
||||
- comms overlay
|
||||
- hangar/action buttons
|
||||
- warning text
|
||||
- canvas saturation/contrast
|
||||
|
||||
## 5. Generator
|
||||
|
||||
The art pack is reproducible through:
|
||||
|
||||
`scripts/generate_magitech_assets.py`
|
||||
|
||||
This script uses the bundled Python runtime with Pillow and generates vector-like raster PNGs. It intentionally avoids relying on one-off manual image files so future palette or silhouette changes can be regenerated consistently.
|
||||
|
||||
## 6. Preview Sheet
|
||||
|
||||
Generated preview sheet:
|
||||
|
||||
`public/sprites/magitech_art_contact_sheet.png`
|
||||
|
||||
The preview sheet is for art review only and is not currently consumed by the game runtime.
|
||||
|
||||
## 7. Follow-up Art Tasks
|
||||
|
||||
Recommended next art pass:
|
||||
|
||||
1. Add animation frame variants for normal and elite enemies.
|
||||
2. Split skill icons into a formal UI icon atlas instead of relying on individual PNGs.
|
||||
3. Add boss-specific silhouettes matching the narrative names in `bossRegistry.ts`.
|
||||
4. Add projectile color language documentation for player, enemy, boss, and gimmick bullets.
|
||||
5. Replace remaining CSS vocabulary from older cyber-neon UI with magitech naming over time.
|
||||
|
||||
## 8. Second Pass Correction
|
||||
|
||||
After user review, the first art pack was judged too childish/cartoon-like. The generator and UI skin were rewritten.
|
||||
|
||||
Second pass changes:
|
||||
|
||||
- removed thick outlines
|
||||
- added brushed metal / stone noise
|
||||
- added stronger shadows and glow-based separation
|
||||
- changed vehicles into darker magitech airships
|
||||
- changed enemies into corrupted mechanical/stone silhouettes
|
||||
- changed backgrounds into darker stone grid ruins with broken circuitry
|
||||
- changed UI from bright toy-card framing to dark iron/crystal framing
|
||||
|
||||
The reproducible generator remains:
|
||||
|
||||
`scripts/generate_magitech_assets.py`
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Hardware]]
|
||||
* [[Metal]]
|
||||
* [[Noise]]
|
||||
* [[Purpose]]
|
||||
* [[Scripts]]
|
||||
+107
@@ -0,0 +1,107 @@
|
||||
# Skybound Stylized Casual Magitech Ingame Asset Fix
|
||||
|
||||
**Date**: 2026-04-24
|
||||
**Project**: Skybound Protocol
|
||||
**Author**: Codex
|
||||
**Status**: Raw follow-up fix from gameplay screenshot review
|
||||
|
||||
## 1. Screenshot Issues
|
||||
|
||||
The reviewed screenshots exposed three in-game visual problems.
|
||||
|
||||
Observed issues:
|
||||
|
||||
- `SUPPLY` air drop was rendered as a simple cyan ring and text label instead of a proper magitech supply crate.
|
||||
- Enemy sprites showed a faint rectangular transparency box around the aircraft body.
|
||||
- Large falling translucent circular hazards were rendered as plain gray circles and did not match the Stylized Casual Magitech tone.
|
||||
|
||||
## 2. Cause
|
||||
|
||||
### Supply Drop
|
||||
|
||||
The supply drop was not using an image asset.
|
||||
|
||||
It was drawn directly in `GameRenderer.renderAirDrops()` as:
|
||||
|
||||
- animated circle stroke
|
||||
- translucent cyan fill
|
||||
- white `SUPPLY` text
|
||||
|
||||
### Enemy Rectangle Artifact
|
||||
|
||||
The procedural generator used glow layers and Lanczos downsampling.
|
||||
|
||||
This left very low alpha pixels across the image canvas. In gameplay, those tiny alpha values became visible as a faint rectangular box around enemies.
|
||||
|
||||
### Falling Circular Hazard
|
||||
|
||||
The falling translucent circle was an `EMP_CLOUD` hazard.
|
||||
|
||||
It was drawn directly in `GameRenderer.renderHazards()` as a generic gray filled circle.
|
||||
|
||||
## 3. Fixes Applied
|
||||
|
||||
### Supply Drop Asset
|
||||
|
||||
A new stylized magitech crate sprite was generated:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/public/sprites/supply_crate.png`
|
||||
|
||||
The renderer now draws this crate for air drops while preserving a small dashed cyan capture ring.
|
||||
|
||||
### Alpha Cleanup
|
||||
|
||||
The procedural asset generator now clamps very low alpha values to `0` during PNG export.
|
||||
|
||||
This removes transparent rectangle artifacts while keeping intended outlines, glow, and silhouettes.
|
||||
|
||||
Verified enemy sprite alpha:
|
||||
|
||||
- normal enemy corner alpha: `0`
|
||||
- elite enemy corner alpha: `0`
|
||||
- boss corner alpha: `0`
|
||||
- no alpha values below the cleanup threshold remain
|
||||
|
||||
### Hazard Assets
|
||||
|
||||
New hazard sprites were generated:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/public/sprites/vfx/vfx_hazard_emp.png`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/public/sprites/vfx/vfx_hazard_asteroid.png`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/public/sprites/vfx/vfx_hazard_debris.png`
|
||||
|
||||
`EMP_CLOUD` now renders as an arcane rune-field instead of a plain gray circle.
|
||||
|
||||
`ASTEROID` and `DEBRIS` can render as stylized magitech rock fragments instead of fallback circles.
|
||||
|
||||
## 4. Changed Runtime Paths
|
||||
|
||||
Important changed or generated paths:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/scripts/generate_magitech_assets.py`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/hooks/useGameAssets.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/GameRenderer.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/utils/SpriteUtils.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/public/sprites/supply_crate.png`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/public/sprites/vfx/vfx_hazard_emp.png`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/public/sprites/vfx/vfx_hazard_asteroid.png`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/public/sprites/vfx/vfx_hazard_debris.png`
|
||||
|
||||
## 5. Verification
|
||||
|
||||
Asset generation completed successfully.
|
||||
|
||||
Alpha inspection confirmed transparent corners and no low-alpha rectangle residue for the checked enemy/boss/supply/hazard sprites.
|
||||
|
||||
Production build completed successfully with:
|
||||
|
||||
```bash
|
||||
npm run build
|
||||
```
|
||||
|
||||
The build still reports the existing `/sprites/player.png` static path warning, but it remains non-blocking and the production bundle was generated successfully.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Reports]]
|
||||
* [[Scripts]]
|
||||
+182
@@ -0,0 +1,182 @@
|
||||
# Skybound Survivor-Like Balance Curve Pass
|
||||
|
||||
**Date**: 2026-04-24
|
||||
**Project**: Skybound Protocol
|
||||
**Author**: Codex
|
||||
**Status**: Raw gameplay balance pass from user playtest feedback
|
||||
|
||||
## 1. Playtest Feedback
|
||||
|
||||
The game shell looked close to Survivor.io / Vampire Survivors, but the actual gameplay did not feel like that genre.
|
||||
|
||||
Reported issues:
|
||||
|
||||
- gameplay did not deliver enough horde-survival pressure
|
||||
- stage balance felt uneven
|
||||
- TAC Level Up pacing felt unbalanced
|
||||
- growth did not form a satisfying user-facing curve
|
||||
|
||||
## 2. Diagnosis
|
||||
|
||||
The previous balance leaned closer to a shmup / tactical shooter.
|
||||
|
||||
Main causes found in code:
|
||||
|
||||
- simultaneous enemy cap was too low for a horde-survival feel
|
||||
- procedural spawn did not fully use the timeline `spawnIntervalMult`
|
||||
- early EXP requirement was too high
|
||||
- EXP growth multiplier was too steep
|
||||
- stage difficulty scaled enemy/bullet stats too aggressively
|
||||
- stage scripted events were compressed too early in the timeline
|
||||
- TAC Level Up card offers were weighted but not structured, so the user could receive awkward choices
|
||||
- starter skill offers could omit key horde-survival archetypes
|
||||
|
||||
## 3. Target Curve
|
||||
|
||||
New target:
|
||||
|
||||
- first meaningful upgrade should arrive quickly
|
||||
- player should see more enemies on screen
|
||||
- enemies should be individually weaker
|
||||
- danger should come from density and positioning, not bullet stat spikes
|
||||
- level-up choices should consistently support build formation
|
||||
- stage progression should rise smoothly rather than jump sharply
|
||||
|
||||
## 4. Applied Balance Changes
|
||||
|
||||
### EXP and Level-Up
|
||||
|
||||
Changes:
|
||||
|
||||
- initial required EXP lowered from `100` to `45`
|
||||
- normal enemy EXP increased from `5` to `7`
|
||||
- elite EXP increased from `25` to `32`
|
||||
- level-up EXP multiplier changed from steep `1.60 / 1.72 / 1.85` to smoother `1.24 / 1.30 / 1.36 / 1.42`
|
||||
|
||||
Expected result:
|
||||
|
||||
- early TAC Level Ups arrive faster
|
||||
- the player can form a build before the first spike
|
||||
- later progression still slows down without becoming a wall
|
||||
|
||||
### TAC Level Up Card Structure
|
||||
|
||||
The card generator now tries to offer:
|
||||
|
||||
- one owned skill upgrade
|
||||
- one synergy / spike-counter / EVO-supporting option
|
||||
- one flexible option
|
||||
|
||||
Expected result:
|
||||
|
||||
- fewer dead-choice screens
|
||||
- higher chance of completing coherent builds
|
||||
- less frustration from random-only card pools
|
||||
|
||||
### Starter Selection
|
||||
|
||||
Starter cards now come from three archetype buckets:
|
||||
|
||||
- primary damage
|
||||
- area / crowd control
|
||||
- utility / defense
|
||||
|
||||
Expected result:
|
||||
|
||||
- every run begins with a usable horde-survival foundation
|
||||
- the first choice feels strategic without becoming punishing
|
||||
|
||||
### Enemy Density and Spawning
|
||||
|
||||
Changes:
|
||||
|
||||
- hard enemy cap increased from `30` to `90`
|
||||
- timeline phase caps increased by stage and phase
|
||||
- procedural spawn interval now uses `spawnIntervalMult`
|
||||
- procedural spawns can arrive in small batches
|
||||
- formation spawns now occur more often
|
||||
- individual enemy HP and speed were reduced to support higher density
|
||||
- elite chance is now a gradual probability instead of flipping too hard by difficulty
|
||||
|
||||
Expected result:
|
||||
|
||||
- more screen-filling horde pressure
|
||||
- less empty movement time
|
||||
- more satisfying weapon-clearing moments
|
||||
|
||||
### Stage Curve
|
||||
|
||||
Changes:
|
||||
|
||||
- stage duration curve changed from `120 + stage * 30s` to `150 + stage * 18s`
|
||||
- stage difficulty scaling reduced from steep `+0.4 per stage` to smoother `+0.18 per stage`
|
||||
- phase difficulty multipliers were lowered
|
||||
- phase enemy caps were increased
|
||||
- scripted wave events are distributed across the stage instead of firing too early
|
||||
|
||||
Expected result:
|
||||
|
||||
- stages feel less spiky and more readable
|
||||
- difficulty rises through density and phase rhythm
|
||||
- player has time to grow before major pressure events
|
||||
|
||||
### Enemy Bullet and Damage Pressure
|
||||
|
||||
Changes:
|
||||
|
||||
- enemy bullet speed curves were reduced
|
||||
- damage curves were reduced
|
||||
- bullet caps were reduced
|
||||
- global enemy bullet speed multiplier reduced
|
||||
- enemy projectile damage multipliers reduced
|
||||
|
||||
Expected result:
|
||||
|
||||
- gameplay moves away from bullet-hell punishment
|
||||
- movement pressure still exists, but horde positioning becomes the main focus
|
||||
|
||||
### Weapon Rhythm
|
||||
|
||||
Several weapon cooldowns were shortened so early picks feel active sooner.
|
||||
|
||||
Nova Burst was also adjusted to trigger sooner and scale more clearly as an AoE crowd-control tool.
|
||||
|
||||
## 5. Changed Runtime Paths
|
||||
|
||||
Important changed paths:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/balance.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/CombatTimeline.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/weaponBehaviors.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/SpawnerSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ProgressionSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/CombatSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ModularWeaponSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/types.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/hooks/useGameEngine.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/store/useGameStore.ts`
|
||||
|
||||
## 6. Verification
|
||||
|
||||
Production build completed successfully with:
|
||||
|
||||
```bash
|
||||
npm run build
|
||||
```
|
||||
|
||||
The existing `/sprites/player.png` static path warning remains non-blocking.
|
||||
|
||||
## 7. Next Playtest Questions
|
||||
|
||||
Recommended next playtest checks:
|
||||
|
||||
- Does the first level-up happen within a satisfying time window?
|
||||
- Does the screen feel populated without becoming unreadable?
|
||||
- Do weapons feel like they clear hordes?
|
||||
- Do stage spikes feel earned rather than sudden?
|
||||
- Does TAC Level Up usually offer at least one desirable choice?
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Events]]
|
||||
* [[Synergy]]
|
||||
+64
@@ -0,0 +1,64 @@
|
||||
# Datacollector - 인증 복구 후 자동 재개 상태 전환 수정
|
||||
|
||||
- 작성 시각: 2026-04-25 22:39:30 KST
|
||||
- 프로젝트: `/Volumes/Data/project/Antigravity/Datacollector`
|
||||
- 관련 파일: `src/components/AgentDashboard.tsx`, `src/lib/engine.ts`
|
||||
|
||||
## 상황
|
||||
|
||||
NotebookLM 인증 복구 로직을 강화했지만, 화면에서는 여전히 `CONTINUE MISSION` 버튼을 사용자가 눌러야 다음 큐가 이어지는 것처럼 보였다.
|
||||
|
||||
사용자 관찰:
|
||||
|
||||
- 작업은 일부 완료됨.
|
||||
- 큐에는 아직 작업이 많이 남아 있음.
|
||||
- 헤더 상태가 `IDLE`로 보임.
|
||||
- `CONTINUE MISSION` 버튼이 사용자의 수동 클릭을 기다림.
|
||||
|
||||
## 원인
|
||||
|
||||
프론트엔드 상태 전환에 빈틈이 있었다.
|
||||
|
||||
`AgentDashboard`의 `useEffect`는 `status !== 'running'`일 때 `KnowledgeEngine.stop()`을 호출한다. 그런데 기존 `stop()`은 내부 실행 플래그만 끄는 것이 아니라 항상 Zustand 상태까지 `idle`로 바꿨다.
|
||||
|
||||
그 결과 인증 오류 등으로 `paused` 상태를 유지해야 하는 경우에도 React effect를 지나면서 `paused -> idle`로 바뀌었다. 이렇게 되면 앱은 "복구 후 자동 재개 가능한 일시정지"가 아니라 "사용자가 다시 Continue를 눌러야 하는 대기 상태"처럼 동작했다.
|
||||
|
||||
## 조치
|
||||
|
||||
`src/lib/engine.ts`:
|
||||
|
||||
- `stop(updateStatus = true)` 형태로 변경했다.
|
||||
- 내부 엔진만 멈춰야 할 때는 UI 상태를 덮어쓰지 않도록 했다.
|
||||
|
||||
`src/components/AgentDashboard.tsx`:
|
||||
|
||||
- `status !== 'running'` effect에서는 `engine.stop(false)`를 호출하도록 변경했다.
|
||||
- `status === 'paused'`이고 큐가 남아 있으면 NotebookLM 연결 확인 후 자동으로 `running`으로 되돌리는 auto-resume effect를 추가했다.
|
||||
- 기존 버그로 이미 `idle`에 갇힌 화면도 구제하기 위해, 수동 정지나 작업 완료 로그가 없는 `idle + 남은 큐` 상태도 복구 가능한 멈춤으로 보고 자동 재개하도록 보강했다.
|
||||
- 중복 자동 재개를 막기 위해 `autoResumeRef` 잠금을 추가했다.
|
||||
|
||||
## 검증
|
||||
|
||||
다음 검증을 완료했다.
|
||||
|
||||
```bash
|
||||
npm run lint
|
||||
curl -sS -I http://127.0.0.1:3000
|
||||
curl -sS -X POST http://127.0.0.1:3002/api/check-connection
|
||||
```
|
||||
|
||||
결과:
|
||||
|
||||
- TypeScript 검사 통과
|
||||
- 프론트엔드 서버 응답 정상
|
||||
- NotebookLM 브리지 연결 확인 `success: true`
|
||||
|
||||
## 운영 메모
|
||||
|
||||
앞으로 인증 복구나 연결 복구로 인해 `paused` 상태가 되면 앱이 NotebookLM 연결을 확인하고 자동으로 다음 큐를 이어서 실행한다.
|
||||
|
||||
사용자가 직접 `STOP / PAUSE`를 누른 경우는 기존처럼 `idle`로 유지되므로, 수동 정지는 자동 재개 대상이 아니다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[React]]
|
||||
+72
@@ -0,0 +1,72 @@
|
||||
# Datacollector Bridge Connection Refused Run Script Fix
|
||||
|
||||
Date: 2026-04-25 21:07:52 KST
|
||||
Project: Datacollector
|
||||
[[Repository|Repository]]: `/Volumes/Data/project/Antigravity/Datacollector`
|
||||
|
||||
## Summary
|
||||
|
||||
사용자가 앱 실행 후 `POST http://127.0.0.1:3002/api/check-connection net::ERR_CONNECTION_REFUSED` 오류를 확인했다.
|
||||
이는 NotebookLM 인증 실패가 아니라 MCP Bridge 서버가 실행되지 않아 브라우저가 `3002` 포트에 연결하지 못한 상태였다.
|
||||
|
||||
## Root Cause
|
||||
|
||||
실행 경로가 여러 개였고 일부 경로는 프런트엔드 Vite 서버만 실행했다.
|
||||
|
||||
- `run_mac.command`: Bridge와 Vite를 함께 실행
|
||||
- `run_app.sh`: Vite만 실행
|
||||
- `npm run dev`: Vite만 실행
|
||||
|
||||
따라서 `run_app.sh` 또는 `npm run dev`로 앱을 켜면 UI는 열리지만 `/api/check-connection` 요청을 받을 Bridge 서버가 없어 `ERR_CONNECTION_REFUSED`가 발생했다.
|
||||
|
||||
## Changes Made
|
||||
|
||||
수정 파일:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/run_app.sh`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/README.md`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/lib/api.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/components/AgentDashboard.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/lib/engine.ts`
|
||||
|
||||
핵심 변경:
|
||||
|
||||
- `run_app.sh`가 Bridge 서버와 Vite 서버를 함께 실행하도록 변경
|
||||
- `run_app.sh` 시작 시 기존 `3000`, `3002` 포트 프로세스를 정리
|
||||
- 종료 시 Bridge 백그라운드 프로세스도 함께 종료하도록 trap 추가
|
||||
- README의 실행 안내를 `npm run dev` 단독에서 `./run_mac.command` 또는 `npm run start-full`로 변경
|
||||
- `src/lib/api.ts`에 `bridgeFetch()` 추가
|
||||
- Bridge 연결 실패 시 `Failed to fetch` 대신 “Bridge 서버가 실행되지 않았다”는 안내 메시지를 표시하도록 변경
|
||||
- `VITE_BRIDGE_URL`로 Bridge 주소를 override할 수 있게 함
|
||||
|
||||
## Verification
|
||||
|
||||
실행한 검증:
|
||||
|
||||
```bash
|
||||
node --check [[Scripts|Scripts]]/mcp_bridge.mjs
|
||||
npm run lint
|
||||
npm run build
|
||||
```
|
||||
|
||||
검증 결과:
|
||||
|
||||
- 브리지 문법 체크 통과
|
||||
- TypeScript 타입체크 통과
|
||||
- Vite 프로덕션 빌드 통과
|
||||
|
||||
## [[Opera|Opera]]tional Note
|
||||
|
||||
앞으로 앱은 아래 방식으로 실행해야 한다.
|
||||
|
||||
```bash
|
||||
./run_mac.command
|
||||
```
|
||||
|
||||
또는 수동으로 두 서버를 같이 실행한다.
|
||||
|
||||
```bash
|
||||
npm run start-full
|
||||
```
|
||||
|
||||
`npm run dev`만 실행하면 프런트엔드만 뜨므로 NotebookLM, Wiki save, 인증 복구 API가 동작하지 않는다.
|
||||
+177
@@ -0,0 +1,177 @@
|
||||
# Datacollector Codebase Structure Review and Initial Risk [[Assessment|Assessment]]
|
||||
|
||||
Date: 2026-04-25 20:38:01 KST
|
||||
Project: Datacollector
|
||||
[[Repository|Repository]]: `/Volumes/Data/project/Antigravity/Datacollector`
|
||||
Knowledge Vault: `/Volumes/Data/project/Antigravity/Wiki/00_Raw`
|
||||
|
||||
## Summary
|
||||
|
||||
이 문서는 Datacollector 프로젝트의 첫 구조 파악 및 초기 코드 리뷰 결과를 정리한 기록이다.
|
||||
이번 검토의 목적은 이후 기능 개발 전에 현재 시스템의 책임 분리, 실행 흐름, 외부 의존성, 그리고 우선적으로 손봐야 할 위험 요소를 이해하는 데 있다.
|
||||
|
||||
현재 프로젝트는 단순한 프런트엔드 앱이 아니라, React 기반 UI와 Zustand 상태 저장소, 자율 실행 엔진, 그리고 NotebookLM MCP 및 로컬 LM을 연결하는 Express 브리지 서버가 결합된 자동화 연구 도구 형태로 구성되어 있다.
|
||||
|
||||
## High-Level [[Architecture|Architecture]]
|
||||
|
||||
전체 흐름은 아래와 같다.
|
||||
|
||||
`React UI -> Zustand Store -> KnowledgeEngine -> Express Bridge -> NotebookLM MCP / Local LM / GitHub / Wiki [[Storage|Storage]]`
|
||||
|
||||
핵심 책임 분리는 다음과 같이 이해했다.
|
||||
|
||||
- `src/components/AgentDashboard.tsx`
|
||||
사용자 인터페이스, 미션 시작/중지/재개, 설정 입력, 로그 표시, 수동 커밋 등 상호작용 담당
|
||||
- `src/store/agentStore.ts`
|
||||
앱 전체 설정값과 실행 상태를 보관하는 단일 전역 상태 저장소
|
||||
- `src/lib/engine.ts`
|
||||
큐를 소비하며 연구, 합성, 링크 추출, 다음 토픽 확장을 반복하는 자율 엔진
|
||||
- `src/lib/gemini.ts`
|
||||
NotebookLM 미연결 시 사용하는 로컬 LM 프롬프트 생성 및 응답 파싱
|
||||
- `src/lib/github.ts`
|
||||
결과 Markdown을 GitHub 저장소의 `00_Raw/` 경로로 업로드
|
||||
- `[[Scripts|Scripts]]/mcp_bridge.mjs`
|
||||
NotebookLM MCP 서버와 통신하는 지속 프로세스형 브리지 서버
|
||||
|
||||
## Execution Flow
|
||||
|
||||
실행 흐름은 다음 순서로 이해했다.
|
||||
|
||||
1. 사용자가 `AgentDashboard`에서 주제를 입력하고 미션을 시작한다.
|
||||
2. 주제와 설정이 `agentStore`에 기록되고 상태가 `running`으로 바뀐다.
|
||||
3. `status` 변경을 감지한 UI가 `KnowledgeEngine` 싱글톤을 시작한다.
|
||||
4. `KnowledgeEngine`는 큐의 첫 항목을 읽고 현재 깊이와 루트 주제를 기준으로 처리 여부를 결정한다.
|
||||
5. NotebookLM 연결 상태가 좋으면 브리지 서버를 통해 리서치와 합성을 수행한다.
|
||||
6. NotebookLM이 없으면 로컬 LM 프록시(`/api/lm`)를 통해 대체 연구를 진행한다.
|
||||
7. 생성된 Markdown에서 위키 링크를 추출해 다음 큐를 구성한다.
|
||||
8. 결과는 pending commits, completed 목록, 로컬 위키 Raw 저장소 등에 반영된다.
|
||||
|
||||
## Current Structure Notes
|
||||
|
||||
이번 시점에서 구조적으로 눈에 띈 특징은 다음과 같다.
|
||||
|
||||
- 상태 관리가 거의 전부 Zustand store 하나에 집중되어 있어 흐름 추적은 쉽다.
|
||||
- 대신 엔진과 UI가 store를 매우 직접적으로 공유해서 결합도가 높다.
|
||||
- NotebookLM 경로와 Local LM 경로가 모두 존재해 fallback 전략은 분명하다.
|
||||
- 브리지 서버가 프런트엔드 백엔드이자 외부 도구 래퍼 역할까지 함께 맡고 있어 책임이 넓다.
|
||||
- 문서 저장 흐름이 GitHub 업로드와 로컬 위키 저장으로 이중화되어 있다.
|
||||
|
||||
## Review Findings
|
||||
|
||||
### 1. Sensitive secrets are persisted in [[Browser|Browser]] storage
|
||||
|
||||
`githubToken`과 `notebookLmCookies`가 Zustand persist 설정에 포함되어 있어 브라우저 localStorage에 평문으로 저장된다.
|
||||
이 방식은 세션 쿠키나 GitHub 토큰 같은 민감 정보의 저장 위치로는 안전하지 않다.
|
||||
|
||||
관련 파일:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/store/agentStore.ts`
|
||||
|
||||
영향:
|
||||
|
||||
- 같은 브라우저 프로필을 사용하는 다른 코드나 도구가 정보에 접근할 수 있다.
|
||||
- 장기적으로 토큰 유출 위험이 커진다.
|
||||
|
||||
### 2. Bridge server is exposed too broadly
|
||||
|
||||
브리지 서버는 `0.0.0.0:3002`로 열리고 CORS도 전부 허용한다.
|
||||
또한 `/api/lm`은 클라이언트가 전달한 임의의 URL로 요청을 프록시할 수 있다.
|
||||
|
||||
관련 파일:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/scripts/mcp_bridge.mjs`
|
||||
|
||||
영향:
|
||||
|
||||
- 로컬 개발용으로는 편하지만, 같은 네트워크 안에서 예상하지 않은 접근 통로가 될 수 있다.
|
||||
- 사실상 무인증 프록시처럼 동작할 여지가 있다.
|
||||
|
||||
### 3. Environment portability is weak
|
||||
|
||||
MCP 실행 파일 경로와 위키 저장 경로가 절대경로로 하드코딩되어 있다.
|
||||
|
||||
관련 파일:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/scripts/mcp_bridge.mjs`
|
||||
|
||||
영향:
|
||||
|
||||
- 다른 개발자 머신, 다른 사용자 계정, 다른 운영체제에서 그대로 실행하기 어렵다.
|
||||
- 배포보다는 특정 개인 작업 환경에 강하게 종속된다.
|
||||
|
||||
### 4. Manual handoff [[State|State]] is not fully cleared
|
||||
|
||||
`resolveManualNext`가 store에 함수 형태로 저장되는데, `clearState()`에서 정리되지 않는다.
|
||||
수동 합성 대기 중 reset 또는 새 미션 시작이 발생하면 상태 꼬임 가능성이 있다.
|
||||
|
||||
관련 파일:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/store/agentStore.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/lib/engine.ts`
|
||||
|
||||
영향:
|
||||
|
||||
- 이전 미션의 대기 상태가 다음 미션에 잔존할 수 있다.
|
||||
- UI 버튼 상태와 실제 엔진 대기 상태가 어긋날 수 있다.
|
||||
|
||||
### 5. API endpoint usage is duplicated and hardcoded
|
||||
|
||||
프런트엔드에는 이미 Vite 프록시가 설정되어 있지만, UI와 엔진 코드 곳곳에서 `http://127.0.0.1:3002`를 직접 호출하고 있다.
|
||||
|
||||
관련 파일:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/components/AgentDashboard.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/lib/engine.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/vite.config.ts`
|
||||
|
||||
영향:
|
||||
|
||||
- 포트 변경이나 배포 환경 변경 시 수정 지점이 늘어난다.
|
||||
- 런타임 경로 설정이 한 군데에서 관리되지 않는다.
|
||||
|
||||
## Validation Performed
|
||||
|
||||
이번 검토 중 아래 확인을 수행했다.
|
||||
|
||||
- 저장소 파일 구조 및 진입점 확인
|
||||
- UI, store, engine, bridge, GitHub, Local LM 계층 코드 확인
|
||||
- `npm run lint` 실행
|
||||
|
||||
검증 결과:
|
||||
|
||||
- TypeScript 타입체크는 현재 통과했다.
|
||||
|
||||
## Suggested Next Priorities
|
||||
|
||||
우선순위는 아래 순서가 적절하다.
|
||||
|
||||
1. 민감 정보 저장 방식을 localStorage 바깥으로 이동하거나 최소한 분리
|
||||
2. 브리지 서버 바인딩 범위와 CORS 정책 축소
|
||||
3. 절대경로를 환경변수 또는 설정 파일로 치환
|
||||
4. `resolveManualNext`를 포함한 미션 종료 정리 로직 강화
|
||||
5. API 베이스 URL을 단일 설정 지점으로 통합
|
||||
|
||||
## Working Agreement For Future Notes
|
||||
|
||||
사용자 요청에 따라, 앞으로 Datacollector 관련 조사/분석/리뷰 결과는 가능하면 이 지식 창고 경로에 계속 기록한다.
|
||||
|
||||
기본 원칙:
|
||||
|
||||
- 위치: `/Volumes/Data/project/Antigravity/Wiki/00_Raw`
|
||||
- 파일명: `YYYY-MM-DD-<Project>_<Topic>.md` 또는 기존 저장소 관례와 유사한 읽기 쉬운 영어 제목
|
||||
- 내용: 작업 목적, 파악한 구조, 핵심 발견사항, 다음 액션을 포함
|
||||
|
||||
## Source Files Reviewed
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/README.md`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/package.json`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/vite.config.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/main.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/App.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/components/AgentDashboard.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/store/agentStore.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/lib/engine.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/lib/gemini.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/lib/github.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/scripts/mcp_bridge.mjs`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/scripts/mcp_caller.py`
|
||||
+74
@@ -0,0 +1,74 @@
|
||||
# Datacollector Local Wiki Save Only Output Mode
|
||||
|
||||
Date: 2026-04-25 20:50:41 KST
|
||||
Project: Datacollector
|
||||
[[Repository|Repository]]: `/Volumes/Data/project/Antigravity/Datacollector`
|
||||
|
||||
## Summary
|
||||
|
||||
Datacollector의 생성 결과 저장 방식을 GitHub 업로드 중심에서 로컬 Wiki 저장 전용으로 정리했다.
|
||||
앞으로 앱에서 생성되는 연구 문서는 `/Volumes/Data/project/Antigravity/Wiki/00_Raw`에 저장되고, Git 업로드는 사용자가 나중에 별도로 한 번에 처리하는 운영 방식으로 둔다.
|
||||
|
||||
## Previous [[Behavior|Behavior]]
|
||||
|
||||
기존 흐름은 결과 생성 후 두 경로가 동시에 존재했다.
|
||||
|
||||
- 로컬 Wiki Raw 폴더에 자동 저장
|
||||
- `pendingCommits`에 결과를 쌓고 UI의 `BATCH COMMIT` 버튼으로 GitHub 업로드 가능
|
||||
|
||||
이 방식은 앱 안에 GitHub 토큰과 저장소 설정을 유지해야 했고, 사용자가 의도하지 않아도 Git 업로드 기능이 계속 노출되는 구조였다.
|
||||
|
||||
## New Behavior
|
||||
|
||||
새 흐름은 다음과 같다.
|
||||
|
||||
1. 연구 결과 Markdown 생성
|
||||
2. `saved[[Reports|Reports]]`에 프리뷰용 로컬 캐시 저장
|
||||
3. 브리지 서버의 `/api/wiki/save`를 통해 `/Volumes/Data/project/Antigravity/Wiki/00_Raw`에 Markdown 파일 저장
|
||||
4. GitHub 업로드 버튼이나 토큰 설정 없이 완료
|
||||
|
||||
GitHub 업로드는 앱이 수행하지 않는다.
|
||||
|
||||
## Changes Made
|
||||
|
||||
수정 파일:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/store/agentStore.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/lib/engine.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/components/AgentDashboard.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/.env.example`
|
||||
|
||||
삭제 파일:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/lib/github.ts`
|
||||
|
||||
핵심 변경:
|
||||
|
||||
- `githubToken`, `githubRepoUrl` 상태 제거
|
||||
- `pendingCommits` 제거
|
||||
- `addPendingCommit`, `clearPendingCommits` 제거
|
||||
- `savedReports`와 `addSavedReport` 추가
|
||||
- `BATCH COMMIT` 버튼 제거
|
||||
- 설정 모달의 GitHub Wiki Sync 섹션 제거
|
||||
- `.env.example`의 GitHub 설정 제거
|
||||
- 생성 결과는 기존 Wiki 저장 API를 통해 로컬 Raw 폴더에만 저장
|
||||
|
||||
## Verification
|
||||
|
||||
실행한 검증:
|
||||
|
||||
```bash
|
||||
npm run lint
|
||||
npm run build
|
||||
```
|
||||
|
||||
검증 결과:
|
||||
|
||||
- TypeScript 타입체크 통과
|
||||
- Vite 프로덕션 빌드 통과
|
||||
|
||||
## Notes
|
||||
|
||||
로컬 Wiki 저장은 기존 브리지 서버의 `/api/wiki/save` 라우트를 그대로 사용한다.
|
||||
저장 대상 경로는 현재 브리지 서버에 하드코딩된 `/Volumes/Data/project/Antigravity/Wiki/00_Raw`이다.
|
||||
추후 이 경로도 `.env` 설정으로 분리하면 다른 머신이나 폴더 구조에서도 더 쉽게 운영할 수 있다.
|
||||
+50
@@ -0,0 +1,50 @@
|
||||
# Datacollector Mac Windows Launcher [[Scripts|Scripts]]
|
||||
|
||||
Date: 2026-04-25 21:09:42 KST
|
||||
Project: Datacollector
|
||||
[[Repository|Repository]]: `/Volumes/Data/project/Antigravity/Datacollector`
|
||||
|
||||
## Summary
|
||||
|
||||
Datacollector 실행 시 Vite 프런트엔드만 뜨고 MCP Bridge 서버가 뜨지 않아 `ERR_CONNECTION_REFUSED`가 발생할 수 있었다.
|
||||
이를 막기 위해 맥용과 윈도우용 실행 파일을 명확히 정리했다.
|
||||
|
||||
## Main Launchers
|
||||
|
||||
- macOS: `/Volumes/Data/project/Antigravity/Datacollector/run_mac.command`
|
||||
- Windows: `/Volumes/Data/project/Antigravity/Datacollector/run_win.bat`
|
||||
|
||||
두 실행 파일 모두 아래를 수행한다.
|
||||
|
||||
1. 프로젝트 폴더로 이동
|
||||
2. `node_modules`가 없으면 `npm install`
|
||||
3. 기존 `3000`, `3002` 포트 프로세스 정리
|
||||
4. MCP Bridge 서버 실행
|
||||
5. Vite 앱 실행
|
||||
|
||||
## Compatibility Wrappers
|
||||
|
||||
기존 실행 파일과의 호환성을 위해 아래 파일은 메인 실행 파일로 위임하도록 단순화했다.
|
||||
|
||||
- `run_app.sh` -> `run_mac.command`
|
||||
- `run_app.bat` -> `run_win.bat`
|
||||
|
||||
## Verification
|
||||
|
||||
실행한 검증:
|
||||
|
||||
```bash
|
||||
bash -n run_mac.command
|
||||
bash -n run_app.sh
|
||||
npm run lint
|
||||
```
|
||||
|
||||
검증 결과:
|
||||
|
||||
- macOS shell script 문법 통과
|
||||
- TypeScript 타입체크 통과
|
||||
|
||||
## [[Opera|Opera]]tional Note
|
||||
|
||||
앞으로 맥에서는 `run_mac.command`, 윈도우에서는 `run_win.bat`만 실행하면 된다.
|
||||
`npm run dev` 단독 실행은 프런트엔드만 켜므로 NotebookLM, Wiki save, 인증 복구 API가 동작하지 않는다.
|
||||
+68
@@ -0,0 +1,68 @@
|
||||
# Datacollector - NotebookLM 인증 브라우저 유지 및 오래된 .env 쿠키 우선순위 문제 해결
|
||||
|
||||
- 작성 시각: 2026-04-25 21:31:00 KST
|
||||
- 프로젝트: `/Volumes/Data/project/Antigravity/Datacollector`
|
||||
- 관련 파일: `[[Scripts|Scripts]]/mcp_bridge.mjs`, `auth_mac.command`, `auth_win.bat`, `.env.example`
|
||||
|
||||
## 상황
|
||||
|
||||
앱에서 `/api/check-connection` 호출이 500으로 실패했고, 화면에는 다음과 같은 메시지가 반복되었다.
|
||||
|
||||
- `Authentication expired`
|
||||
- `인증 자동 복구 실패. 브라우저 로그인이 필요한 상태일 수 있습니다.`
|
||||
- `MCP initialized: true, pending: 0`
|
||||
|
||||
사용자는 NotebookLM 인증 중 [[Chrome|Chrome]]이 열렸다가 닫히는 점을 보고, 인증 브라우저를 유지해야 하는 것 아니냐고 질문했다.
|
||||
|
||||
## 확인한 내용
|
||||
|
||||
`notebooklm-mcp-auth` 소스 확인 결과, 기본 자동 실행 모드는 인증 후 자신이 띄운 Chrome 프로세스를 종료한다. 반면 `--no-auto-launch --port ... --user-data-dir ...` 모드는 이미 떠 있는 Chrome 디버깅 세션에 붙기 때문에 인증 브라우저를 유지할 수 있다.
|
||||
|
||||
브리지에서 Chrome을 유지하도록 바꾼 뒤 인증 CLI는 성공했다. 하지만 MCP 서버의 `notebook_list`는 여전히 `Authentication expired`를 반환했다.
|
||||
|
||||
추가 확인 결과, `.env`에 예전 `NOTEBOOKLM_COOKIES` 값이 남아 있었다. `scripts/mcp_bridge.mjs`가 `dotenv/config`를 로드한 뒤 MCP 서버를 자식 프로세스로 실행하면서 이 오래된 환경변수 쿠키가 `~/.notebooklm-mcp/auth.json`의 최신 인증 캐시보다 우선 적용되고 있었다.
|
||||
|
||||
즉 실제 핵심 원인은 다음 조합이었다.
|
||||
|
||||
- 인증 CLI는 최신 쿠키를 `~/.notebooklm-mcp/auth.json`에 정상 저장함.
|
||||
- 브리지는 `.env`의 오래된 `NOTEBOOKLM_COOKIES`를 MCP 자식 프로세스에 전달함.
|
||||
- MCP 서버는 캐시 파일보다 환경변수를 우선 사용함.
|
||||
- 결과적으로 새 인증 후에도 MCP는 계속 오래된 쿠키로 NotebookLM API를 호출함.
|
||||
|
||||
## 조치
|
||||
|
||||
`scripts/mcp_bridge.mjs`에서 기본적으로 MCP 자식 프로세스와 인증 CLI 자식 프로세스에 `NOTEBOOKLM_COOKIES`, `NOTEBOOKLM_CSRF_TOKEN`, `NOTEBOOKLM_SESSION_ID`를 넘기지 않도록 수정했다.
|
||||
|
||||
명시적으로 환경변수 인증을 사용해야 할 경우에는 `.env`에 아래 값을 둔다.
|
||||
|
||||
```env
|
||||
USE_NOTEBOOKLM_ENV_AUTH="true"
|
||||
```
|
||||
|
||||
기본값은 `false`이며, 이 경우 `notebooklm-mcp-auth`가 생성한 `~/.notebooklm-mcp/auth.json` 캐시를 우선 사용한다.
|
||||
|
||||
또한 `auth_mac.command`, `auth_win.bat`는 별도 Chrome 프로필과 디버깅 포트를 사용해 NotebookLM 인증 브라우저를 열어두는 방식으로 변경했다.
|
||||
|
||||
## 검증
|
||||
|
||||
다음 검증을 완료했다.
|
||||
|
||||
```bash
|
||||
node --check scripts/mcp_bridge.mjs
|
||||
npm run lint
|
||||
curl -sS -X POST http://127.0.0.1:3002/api/check-connection
|
||||
```
|
||||
|
||||
결과:
|
||||
|
||||
```json
|
||||
{"success":true,"count":0}
|
||||
```
|
||||
|
||||
직접 Python MCP 클라이언트로도 같은 인증 캐시를 사용해 `list_notebooks` 호출이 성공했고, 노트북 89개를 읽는 것을 확인했다.
|
||||
|
||||
## 운영 메모
|
||||
|
||||
앞으로는 `.env`에 오래된 `NOTEBOOKLM_COOKIES`가 남아 있어도 기본 브리지 실행에는 영향을 주지 않는다. 다만 혼란을 줄이려면 장기적으로 `.env`에서 `NOTEBOOKLM_COOKIES` 줄을 삭제하거나 주석 처리하는 것이 좋다.
|
||||
|
||||
NotebookLM 인증용 Chrome 창은 닫지 않는 것이 좋다. 인증이 풀렸을 때 브리지가 같은 디버깅 포트의 Chrome 세션에 붙어 자동 복구를 시도할 수 있다.
|
||||
+85
@@ -0,0 +1,85 @@
|
||||
# Datacollector NotebookLM Automatic Auth Recovery
|
||||
|
||||
Date: 2026-04-25 20:47:05 KST
|
||||
Project: Datacollector
|
||||
[[Repository|Repository]]: `/Volumes/Data/project/Antigravity/Datacollector`
|
||||
|
||||
## Summary
|
||||
|
||||
컴퓨터 포맷 이후 NotebookLM MCP 인증이 자주 실패하고, 20-30분마다 `auth_mac.command`를 수동 실행해야 하는 문제가 있었다.
|
||||
이번 작업에서는 인증 만료 시 브리지 서버가 자동으로 복구를 시도하도록 개선했다.
|
||||
|
||||
## Root Cause Hypothesis
|
||||
|
||||
기존 구조는 MCP 서버의 `refresh_auth` 도구 호출에만 의존했다.
|
||||
하지만 포맷 이후 로컬 토큰 저장 위치나 [[Chrome|Chrome]] 세션 상태가 달라지면서 `refresh_auth`만으로 복구되지 않는 상황이 발생할 수 있다.
|
||||
|
||||
사용자가 직접 실행하던 파일은 다음 명령의 래퍼였다.
|
||||
|
||||
```bash
|
||||
/Users/g1nation_mac/.local/bin/notebooklm-mcp-auth
|
||||
```
|
||||
|
||||
따라서 자동 복구 흐름에도 이 CLI 인증 명령을 포함시키는 것이 가장 직접적인 개선 방향이다.
|
||||
|
||||
## Changes Made
|
||||
|
||||
수정 파일:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/[[Scripts|Scripts]]/mcp_bridge.mjs`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/components/AgentDashboard.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/.env.example`
|
||||
|
||||
핵심 변경:
|
||||
|
||||
- 브리지 서버가 `.env`를 읽도록 `dotenv/config`를 추가했다.
|
||||
- `AUTH_PATH`, `AUTH_ARGS`, `AUTH_TIMEOUT_MS`, `AUTH_REFRESH_INTERVAL_MS` 설정을 추가했다.
|
||||
- MCP 인증 에러 발생 시 `refresh_auth`를 먼저 시도한다.
|
||||
- `refresh_auth` 실패 시 MCP 프로세스를 재시작하고 다시 갱신을 시도한다.
|
||||
- 그래도 실패하면 `notebooklm-mcp-auth` CLI를 브리지 서버가 직접 실행한다.
|
||||
- CLI 인증 후 MCP 프로세스를 재시작해 새 토큰을 읽게 만든다.
|
||||
- 장시간 실행 중에는 15분 간격으로 요청이 없는 시점에 인증 상태를 사전 갱신한다.
|
||||
- UI 안내 문구를 수동 재인증 중심에서 자동 복구 중심으로 수정했다.
|
||||
|
||||
## Runtime [[Behavior|Behavior]]
|
||||
|
||||
새 인증 복구 순서:
|
||||
|
||||
1. NotebookLM MCP 요청 실패
|
||||
2. 에러 메시지가 인증 관련인지 판단
|
||||
3. `refresh_auth` 호출
|
||||
4. MCP 프로세스 재시작 후 `refresh_auth` 재시도
|
||||
5. `notebooklm-mcp-auth` CLI 자동 실행
|
||||
6. MCP 프로세스 재시작
|
||||
7. 원래 실패했던 NotebookLM 요청 재시도
|
||||
|
||||
주기적 갱신:
|
||||
|
||||
- 기본 간격: 15분
|
||||
- 설정값: `AUTH_REFRESH_INTERVAL_MS=900000`
|
||||
- 진행 중인 MCP 요청이 있을 때는 건드리지 않고 건너뛴다.
|
||||
|
||||
## Verification
|
||||
|
||||
실행한 검증:
|
||||
|
||||
```bash
|
||||
node --check scripts/mcp_bridge.mjs
|
||||
npm run lint
|
||||
npm run bridge
|
||||
curl -s http://127.0.0.1:3002/api/health
|
||||
```
|
||||
|
||||
검증 결과:
|
||||
|
||||
- `node --check` 통과
|
||||
- TypeScript 타입체크 통과
|
||||
- 브리지 서버 시작 성공
|
||||
- MCP 서버 초기화 성공
|
||||
- `/api/health`에서 `connected: true`, `version: 3.3.0`, `authPath` 확인
|
||||
|
||||
## Notes
|
||||
|
||||
완전히 백그라운드 인증이 가능한지는 Google/Chrome 세션 상태에 의존한다.
|
||||
브라우저 로그인이 만료되어 실제 사용자 로그인이 필요한 상태라면 자동 CLI 실행도 브라우저 로그인을 요구할 수 있다.
|
||||
다만 기존처럼 매번 사용자가 batch 파일을 직접 실행하는 흐름보다, 일반적인 토큰 만료와 MCP refresh 실패 상황은 브리지 서버가 먼저 복구하도록 개선되었다.
|
||||
+60
@@ -0,0 +1,60 @@
|
||||
# Datacollector - NotebookLM 자동 재인증 검증 강화 및 동시 복구 잠금
|
||||
|
||||
- 작성 시각: 2026-04-25 22:17:33 KST
|
||||
- 프로젝트: `/Volumes/Data/project/Antigravity/Datacollector`
|
||||
- 관련 파일: `[[Scripts|Scripts]]/mcp_bridge.mjs`
|
||||
|
||||
## 상황
|
||||
|
||||
인증 브라우저 유지와 오래된 `.env` 쿠키 우선순위 문제를 해결한 뒤에도, 실제 작업 중 인증이 풀렸을 때 완전히 자동으로 재인증되지 않는 문제가 남아 있었다.
|
||||
|
||||
화면에서는 작업은 진행되지만 사용자가 기대한 "인증 만료 감지 -> 자동 재인증 -> 원래 작업 재시도" 흐름이 안정적으로 보장되지 않았다.
|
||||
|
||||
## 원인
|
||||
|
||||
브리지에는 자동 복구 로직이 있었지만 두 가지 빈틈이 있었다.
|
||||
|
||||
- `refresh_auth` 호출이 성공해도 실제 NotebookLM API 호출이 가능한지 검증하지 않았다.
|
||||
- `/api/re-auth`와 `/api/check-connection` 같은 요청이 동시에 들어오면 각각 MCP 재시작과 인증 복구를 시도해서 프로세스 재시작 경합이 생길 수 있었다.
|
||||
|
||||
추가로 인증 오류 판별 문자열에 `expired`, `RPC Error 16`, `csrf`, `만료` 같은 케이스가 충분히 포함되지 않아 일부 인증 만료 메시지가 일반 오류로 처리될 가능성이 있었다.
|
||||
|
||||
## 조치
|
||||
|
||||
`scripts/mcp_bridge.mjs`에서 다음을 수정했다.
|
||||
|
||||
- 재인증 성공 기준을 `refresh_auth` 성공이 아니라 실제 `notebook_list` 호출 성공으로 강화했다.
|
||||
- 인증 만료 감지 시 `refreshAuth({ allowExternalAuth: true })`를 통해 자동 CLI 인증 복구까지 이어지도록 정리했다.
|
||||
- 주기적 인증 점검도 필요 시 외부 인증 CLI 복구를 허용하도록 변경했다.
|
||||
- `_refreshAuthPromise` 잠금을 추가해 동시 재인증/재시작 요청이 서로 충돌하지 않게 했다.
|
||||
- 인증 오류 감지 키워드에 `expired`, `rpc error 16`, `csrf`, `unauthorized`, `forbidden`, `인증`, `만료`를 추가했다.
|
||||
|
||||
## 검증
|
||||
|
||||
다음 검증을 완료했다.
|
||||
|
||||
```bash
|
||||
node --check scripts/mcp_bridge.mjs
|
||||
npm run lint
|
||||
curl -sS -X POST http://127.0.0.1:3002/api/re-auth
|
||||
curl -sS -X POST http://127.0.0.1:3002/api/check-connection
|
||||
```
|
||||
|
||||
결과:
|
||||
|
||||
- `/api/re-auth`: `success: true`
|
||||
- `/api/check-connection`: `success: true`
|
||||
|
||||
또한 `/api/re-auth`와 `/api/check-connection`을 동시에 호출해도 둘 다 성공하는 것을 확인했다.
|
||||
|
||||
## 운영 메모
|
||||
|
||||
이제 인증이 풀린 상태에서 NotebookLM MCP 호출이 인증 오류를 반환하면 브리지가 다음 순서로 자동 복구한다.
|
||||
|
||||
1. MCP의 `refresh_auth` 실행
|
||||
2. 실제 `notebook_list` 호출로 인증 유효성 검증
|
||||
3. 실패 시 MCP 프로세스 재시작 후 재검증
|
||||
4. 그래도 실패하면 `notebooklm-mcp-auth` CLI 실행
|
||||
5. 인증 캐시 정리 후 MCP 재시작 및 실제 호출 검증
|
||||
|
||||
NotebookLM 브라우저 세션이 완전히 로그아웃된 상태라면 자동 CLI도 브라우저 로그인을 요구할 수 있다. 이 경우 사용자가 열린 NotebookLM [[Chrome|Chrome]] 창에서 로그인만 해두면 이후 자동 복구가 다시 이어질 수 있다.
|
||||
+70
@@ -0,0 +1,70 @@
|
||||
# Datacollector NotebookLM Progress Visibility and Auth Diagnosis
|
||||
|
||||
Date: 2026-04-25 21:17:24 KST
|
||||
Project: Datacollector
|
||||
[[Repository|Repository]]: `/Volumes/Data/project/Antigravity/Datacollector`
|
||||
|
||||
## Summary
|
||||
|
||||
사용자가 UI에서 `NotebookLM 연결 상태 점검 중...` 로그만 반복되고 실제 진행 상황을 알 수 없다고 보고했다.
|
||||
확인 결과 앱이 프로젝트 생성 단계까지 가지 못하고 있었으며, 원인은 NotebookLM 연결 확인 단계에서 MCP 인증이 만료 상태로 판단되기 때문이었다.
|
||||
|
||||
## Observed [[State|State]]
|
||||
|
||||
확인한 상태:
|
||||
|
||||
- Vite 서버 `3000` 실행 중
|
||||
- MCP Bridge 서버 `3002` 실행 중
|
||||
- `notebooklm-mcp` 프로세스 실행 중
|
||||
- `/api/health` 응답 가능
|
||||
- `/api/check-connection`은 NotebookLM 인증 만료 오류 반환
|
||||
|
||||
브리지 로그상 자동 인증 CLI는 [[Chrome|Chrome]]을 열고 로그인 및 토큰 추출까지 수행했다.
|
||||
그러나 MCP 서버는 이후에도 `Authentication expired`로 판단하여 NotebookLM notebook list 호출에 실패했다.
|
||||
|
||||
## Changes Made
|
||||
|
||||
수정 파일:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/[[Scripts|Scripts]]/mcp_bridge.mjs`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/components/AgentDashboard.tsx`
|
||||
|
||||
핵심 변경:
|
||||
|
||||
- MCP 초기화 타임아웃 추가: `MCP_INIT_TIMEOUT_MS`
|
||||
- NotebookLM 연결 확인 타임아웃 추가: `MCP_HEALTH_TIMEOUT_MS`
|
||||
- `/api/health`에 상세 상태 추가
|
||||
- `initialized`, `processRunning`, `processPid`, `pendingRequests`, `authStatus` 노출
|
||||
- 인증 CLI 진행 단계(`starting`, `running`, `restarting`, `success`, `failed`) 추적
|
||||
- UI 연결 점검 중 5초마다 Bridge/MCP/auth 진행 상태 로그 출력
|
||||
- 중복 연결 점검 요청은 기존 Promise를 재사용하도록 변경
|
||||
|
||||
## Verification
|
||||
|
||||
실행한 검증:
|
||||
|
||||
```bash
|
||||
node --check scripts/mcp_bridge.mjs
|
||||
npm run lint
|
||||
npm run build
|
||||
curl -sS --max-time 5 http://127.0.0.1:3002/api/health
|
||||
curl -sS --max-time 25 -X POST -H 'Content-Type: application/json' -d '{}' http://127.0.0.1:3002/api/check-connection
|
||||
```
|
||||
|
||||
검증 결과:
|
||||
|
||||
- 브리지 문법 체크 통과
|
||||
- TypeScript 타입체크 통과
|
||||
- Vite 빌드 통과
|
||||
- Bridge/MCP 프로세스는 실행됨
|
||||
- NotebookLM 연결 확인은 인증 만료 오류로 실패
|
||||
|
||||
## Current Diagnosis
|
||||
|
||||
현재 문제는 앱 실행이나 Bridge 연결 문제가 아니라 NotebookLM MCP 인증 상태 문제다.
|
||||
자동 인증 CLI가 토큰을 저장해도 MCP 서버가 계속 만료로 판단하므로, 다음 단계에서는 NotebookLM MCP 패키지의 인증 저장 형식 또는 권장 인증 방식(`--file` 모드 등)을 확인해야 한다.
|
||||
|
||||
## [[Opera|Opera]]tional Note
|
||||
|
||||
확인용으로 실행했던 Bridge/Vite/MCP 프로세스는 종료했다.
|
||||
새 진행 상태 로그를 보려면 앱을 `run_mac.command`로 다시 실행해야 한다.
|
||||
+175
@@ -0,0 +1,175 @@
|
||||
# Skybound HP Scarcity and Module Cache Rewards
|
||||
|
||||
작성일: 2026-04-26 13:01 KST
|
||||
|
||||
## 요청 요약
|
||||
|
||||
- Stage 1 플레이 중 하트 HP 회복 아이템이 너무 자주 드롭되어 위기감이 사라지는 문제를 개선한다.
|
||||
- 초반에는 어느 정도 회복을 주되, 항상 충분하게 주기보다 “조금 아쉬운” 수준으로 조정한다.
|
||||
- 전투 중 모듈이 자동 지급되어 획득 재미가 떨어지는 문제를 개선한다.
|
||||
- 보물 상자 혹은 모듈 상자 이미지를 만들고, 사용자 인벤토리에 stacking되게 한다.
|
||||
- 상자를 열었을 때 모듈 획득 이펙트와 연출을 추가한다.
|
||||
- 일반 등급은 기본 연출, 상급 이상은 개봉 중 기대감을 줄 수 있는 힌트 연출을 제공한다.
|
||||
|
||||
## 핵심 문제
|
||||
|
||||
기존 보상 구조는 적 처치 시 장비가 곧바로 `inventory`에 추가되는 방식이었다.
|
||||
|
||||
이 구조는 기능적으로는 빠르지만, 사용자가 다음 감각을 느끼기 어렵다.
|
||||
|
||||
1. 내가 무언가를 얻었다는 소유감
|
||||
2. 전투 후 보상을 확인하는 기대감
|
||||
3. 상자를 열 때 “이번에는 뭐가 나올까” 하는 가챠/루팅 재미
|
||||
4. 등급별 보상의 차이
|
||||
|
||||
또한 하트 드롭은 대량의 적 처치 수와 결합되면서 체력 결핍이 거의 발생하지 않는 상태를 만들었다.
|
||||
|
||||
## 적용한 변경
|
||||
|
||||
### HP 회복 아이템 희소화
|
||||
|
||||
기존에는 적 처치 시 25% 확률로 필드 아이템이 나오고, 그중 일부가 HP 회복 아이템이었다.
|
||||
|
||||
변경 후에는 체력 상태와 쿨다운을 기반으로 HP 드롭을 계산한다.
|
||||
|
||||
- HP가 82% 이상이면 하트 드롭이 거의 발생하지 않는다.
|
||||
- HP가 60% 미만일 때부터 하트 확률이 의미 있게 상승한다.
|
||||
- HP가 35% 미만이면 긴급 회복 가능성을 열어둔다.
|
||||
- 하트 드롭 후에는 기본 900프레임 쿨다운을 둔다.
|
||||
- 위기 상황에서는 쿨다운을 480프레임으로 낮춰 완전한 운빨 사망은 줄인다.
|
||||
- 엘리트와 미니보스는 회복/보상 드롭 가능성이 조금 더 높다.
|
||||
|
||||
### 회복량 조정
|
||||
|
||||
하트 하나가 체력을 너무 크게 회복하지 않도록 회복량을 낮췄다.
|
||||
|
||||
변경 전:
|
||||
|
||||
- 필드 하트: 최대 HP의 20%
|
||||
- 회복 에어드롭: 최대 HP의 40%
|
||||
|
||||
변경 후:
|
||||
|
||||
- 필드 하트: 최대 HP의 14%
|
||||
- 회복 에어드롭: 최대 HP의 32%
|
||||
|
||||
목표는 “살았다”는 안도감은 주되, 바로 100% 안정권으로 돌아가지 않게 만드는 것이다.
|
||||
|
||||
### 자동 모듈 지급 제거
|
||||
|
||||
일반 적 처치 시 장비가 직접 지급되는 흐름을 제거했다.
|
||||
|
||||
변경 후:
|
||||
|
||||
- 일반 적은 장비/모듈 캐시를 지급하지 않는다.
|
||||
- 엘리트, 미니보스, 보스 보상은 즉시 장비 지급이 아니라 `Module Cache`로 전환된다.
|
||||
- 캐시는 격납고 인벤토리에 stacking된다.
|
||||
- 실제 장비는 사용자가 캐시를 열 때 생성된다.
|
||||
|
||||
이제 전투 중에는 “보상 상자를 회수했다”는 흐름이 되고, 장비 획득은 격납고에서 별도 개봉 경험으로 분리된다.
|
||||
|
||||
### Module Cache 인벤토리 추가
|
||||
|
||||
`useGameStore`에 `moduleCaches` 상태와 액션을 추가했다.
|
||||
|
||||
추가된 액션:
|
||||
|
||||
- `addModuleCache(cache)`
|
||||
- `openModuleCache(cacheId)`
|
||||
|
||||
`openModuleCache`는 캐시의 등급과 클래스 정보를 기반으로 장비를 생성하고, 해당 장비를 `inventory`에 `isNew` 상태로 추가한다.
|
||||
|
||||
### Module Cache 이미지 추가
|
||||
|
||||
톤앤매너에 맞춘 Stylized Casual Magitech 상자 SVG를 추가했다.
|
||||
|
||||
특징:
|
||||
|
||||
- 굵은 외곽선
|
||||
- 시안/라임 마력 코어
|
||||
- 블루 메탈 케이스
|
||||
- 골드 띠 장식
|
||||
- 상자 개봉 UI에서 재사용 가능한 벡터 에셋
|
||||
|
||||
추가 파일:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/public/sprites/module_cache.svg`
|
||||
|
||||
### 격납고 Module Cache UI 추가
|
||||
|
||||
`HangarOverlay`의 Loadout 탭에 `Module Caches` 섹션을 추가했다.
|
||||
|
||||
UI 동작:
|
||||
|
||||
- 같은 등급/클래스/출처의 캐시는 하나의 카드로 stacking 표시된다.
|
||||
- 카드에는 `xN` 카운트가 표시된다.
|
||||
- Elite Cache, Command Cache, Boss Cache 출처가 표시된다.
|
||||
- 클릭하면 해당 캐시 1개를 개봉한다.
|
||||
|
||||
### 등급별 개봉 연출 추가
|
||||
|
||||
캐시 개봉 시 별도 오버레이가 뜨도록 했다.
|
||||
|
||||
연출 구성:
|
||||
|
||||
- 어두운 배경 블러
|
||||
- 캐시 중심 이미지
|
||||
- 등급 색상 기반 발광
|
||||
- 회전하는 아케인 링
|
||||
- 작은 마력 스파크
|
||||
- 개봉 중 힌트 텍스트
|
||||
- 최종 모듈 이름/타입/스탯 공개
|
||||
|
||||
일반 등급은 짧은 기본 개봉으로 처리하고, GOOD 이상은 개봉 중 다음 힌트를 보여준다.
|
||||
|
||||
- 모듈 타입 신호
|
||||
- 보상 출처
|
||||
- 등급 신호 안정화 문구
|
||||
|
||||
이를 통해 상급 이상 상자는 결과 공개 전 기대감을 주는 구조로 만들었다.
|
||||
|
||||
## 설계 의도
|
||||
|
||||
이번 패스의 목표는 Stage 1의 생존 긴장감과 보상 기대감을 동시에 살리는 것이다.
|
||||
|
||||
하트는 플레이어를 완전히 방치하지 않되, 항상 충분하게 주지 않는다.
|
||||
|
||||
모듈은 자동 지급에서 상자 개봉으로 바꿔 다음 루프를 만든다.
|
||||
|
||||
1. 전투에서 엘리트/보스 처치
|
||||
2. 모듈 캐시 획득
|
||||
3. 격납고로 복귀
|
||||
4. 캐시 stack 확인
|
||||
5. 캐시 개봉
|
||||
6. 모듈 획득
|
||||
7. 장착/합성/분해 선택
|
||||
|
||||
이 구조는 Vampire Survivors류의 런 성장과 Survivor.io류의 메타 보상 사이를 이어주는 역할을 한다.
|
||||
|
||||
## 수정 파일
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/public/sprites/module_cache.svg`
|
||||
- `/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/StageDirectorSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/types.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/HangarOverlay.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/HangarOverlay.css`
|
||||
|
||||
## 검증
|
||||
|
||||
- `npm run build` 성공
|
||||
- `/sprites/player.png` 경고 없음
|
||||
- 출력 디렉터리: `dist/24`
|
||||
|
||||
## 후속 플레이테스트 체크 포인트
|
||||
|
||||
- Stage 1 초반 하트가 너무 부족해서 불합리하게 느껴지지 않는지 확인한다.
|
||||
- Stage 1 중반 이후 체력이 즉시 100%로 복구되는 빈도가 줄었는지 확인한다.
|
||||
- 엘리트/보스 처치 후 캐시 획득 문구가 보상처럼 느껴지는지 확인한다.
|
||||
- 격납고에서 캐시 stack UI가 충분히 명확한지 확인한다.
|
||||
- GOOD 이상 캐시 개봉 시 “뭐가 나올까” 하는 기대감이 생기는지 확인한다.
|
||||
- 캐시 개봉 후 모듈이 `Module Storage`에 자연스럽게 추가되는지 확인한다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
+136
@@ -0,0 +1,136 @@
|
||||
# Skybound Invasion Response Stage Difficulty Curve
|
||||
|
||||
작성일: 2026-04-26 13:08 KST
|
||||
|
||||
## 요청 요약
|
||||
|
||||
- Stage 8 보스가 지구를 침략한 핵심 적이라는 스토리 구조를 난이도 곡선에 반영한다.
|
||||
- 초반에는 플레이어를 얕보고 소수의 적기만 보내는 느낌으로 시작한다.
|
||||
- 스테이지를 클리어할수록 보스가 플레이어를 점점 더 위험하게 판단하고, 단계적으로 더 많은 적기를 투입한다.
|
||||
- 적기의 수가 줄어든 구간은 너무 쉬워질 수 있으므로 적기의 공격력을 비례해서 보정한다.
|
||||
|
||||
## 핵심 방향
|
||||
|
||||
이번 패스는 단순히 숫자를 올리는 밸런스가 아니라 “침공군의 대응 수위”를 만드는 작업이다.
|
||||
|
||||
설계 기준은 다음과 같다.
|
||||
|
||||
1. Stage 1: 정찰대. 적 수는 적지만 한 발은 무시할 수 없다.
|
||||
2. Stage 2: 빠른 대응기 투입. 아직 소규모지만 반응 속도가 오른다.
|
||||
3. Stage 3: 혼합 편대. 보스가 플레이어를 실제 변수로 인식한다.
|
||||
4. Stage 4: 제압 작전. 십자/라인 압박이 본격화된다.
|
||||
5. Stage 5: 전면 공격 승인. 적 수가 확실히 늘어난다.
|
||||
6. Stage 6: 제거 함대. 빌드 완성도를 검증한다.
|
||||
7. Stage 7: 예비 전력 투입. 물량과 엘리트 압박이 커진다.
|
||||
8. Stage 8: 지구 침공 본대. 최대 물량과 최대 화력으로 압박한다.
|
||||
|
||||
## 적용한 변경
|
||||
|
||||
### Stage Profile 재정렬
|
||||
|
||||
`SURVIVOR_STAGE_PROFILES`를 8단계 침공 대응 곡선으로 재배치했다.
|
||||
|
||||
변경된 주요 축:
|
||||
|
||||
- `diffBase`
|
||||
- `capBase`
|
||||
- `spawnTempo`
|
||||
- opening wave density
|
||||
- swarm density
|
||||
- climax elite density
|
||||
- comms 문구
|
||||
|
||||
### 초반 적 수 감소
|
||||
|
||||
Stage 1과 Stage 2는 보스가 플레이어를 얕보는 단계로 설정했다.
|
||||
|
||||
Stage 1 변경:
|
||||
|
||||
- `capBase: 18` → `12`
|
||||
- `spawnTempo: 1.0` → `1.18`
|
||||
- opening density: `8` → `4`
|
||||
- swarm density: `18` → `12`
|
||||
- climax elite density: `3` → `2`
|
||||
|
||||
Stage 2 변경:
|
||||
|
||||
- `capBase: 28` → `16`
|
||||
- `spawnTempo: 0.86` → `1.02`
|
||||
- opening density: `14` → `7`
|
||||
- swarm density: `24` → `16`
|
||||
- climax elite density: `4` → `3`
|
||||
|
||||
초반에는 화면을 적으로 가득 채우기보다, 각 적기의 진입과 탄환을 플레이어가 인식할 수 있게 만들었다.
|
||||
|
||||
### 중후반 적 수 증가 곡선 강화
|
||||
|
||||
Stage 5부터는 침공군이 실제로 플레이어 제거를 목표로 움직이는 느낌을 강화했다.
|
||||
|
||||
후반 주요 변화:
|
||||
|
||||
- Stage 5 `capBase: 40` → `34`, 대신 `diffBase: 1.42` → `1.54`
|
||||
- Stage 6 `capBase: 46` → `42`, `diffBase: 1.58` → `1.74`
|
||||
- Stage 7 `capBase: 52` → `50`, `diffBase: 1.76` → `1.96`
|
||||
- Stage 8 `capBase: 58` → `60`, `diffBase: 1.96` → `2.22`
|
||||
- Stage 8 swarm density: `60` → `68`
|
||||
- Stage 8 climax elite density: `10` → `12`
|
||||
|
||||
Stage 5-7은 성능과 가독성을 고려해 단순 물량만 폭증시키지 않고, 공격 위협을 함께 올렸다.
|
||||
|
||||
### 공격력 보정
|
||||
|
||||
적 수가 줄어든 스테이지가 너무 쉬워지는 것을 방지하기 위해 `DAMAGE_CURVE`를 상향했다.
|
||||
|
||||
변경 전:
|
||||
|
||||
- `[0.95, 1.08, 1.24, 1.44, 1.68, 1.96, 2.28, 2.65]`
|
||||
|
||||
변경 후:
|
||||
|
||||
- `[1.08, 1.16, 1.32, 1.52, 1.78, 2.08, 2.44, 2.88]`
|
||||
|
||||
의도는 “적 수가 적으면 회피 기회가 많아지는 만큼, 맞았을 때는 실수로 느껴지게 하는 것”이다.
|
||||
|
||||
### Comms 서사 반영
|
||||
|
||||
스테이지 시작/주요 웨이브 문구를 침공 대응 서사에 맞게 수정했다.
|
||||
|
||||
예시:
|
||||
|
||||
- Stage 1: `Scout flight detected. The invader is probing our response.`
|
||||
- Stage 2: `Stage 2: the invader is testing faster response craft.`
|
||||
- Stage 4: `Stage 4: the invader is no longer probing. Suppression grid active.`
|
||||
- Stage 8: `Stage 8: planetary invasion force confirmed. Survive the crush.`
|
||||
|
||||
## 설계 의도
|
||||
|
||||
이번 변경의 핵심은 플레이어가 난이도 상승을 “게임이 갑자기 어려워졌다”가 아니라 “보스가 나를 점점 더 심각한 위협으로 보고 있다”라고 받아들이게 만드는 것이다.
|
||||
|
||||
초반은 적 수가 줄어들었기 때문에 회피와 학습의 여유가 있다.
|
||||
|
||||
하지만 공격력은 낮추지 않고 오히려 보정했기 때문에, 가만히 있어도 쉽게 깨지는 구조는 피한다.
|
||||
|
||||
후반은 플레이어 빌드가 강해지는 것을 전제로, 적 수와 공격력이 함께 올라간다.
|
||||
|
||||
## 수정 파일
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/CombatTimeline.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/balance.ts`
|
||||
|
||||
## 검증
|
||||
|
||||
- `npm run build` 성공
|
||||
- `/sprites/player.png` 경고 없음
|
||||
- 출력 디렉터리: `dist/25`
|
||||
|
||||
## 후속 플레이테스트 체크 포인트
|
||||
|
||||
- Stage 1 초반이 “적이 적어서 심심한지” 또는 “소수지만 긴장감이 있는지” 확인한다.
|
||||
- Stage 1에서 맞았을 때 피격이 의미 있게 느껴지는지 확인한다.
|
||||
- Stage 2가 Stage 1보다 확실히 대응 수위가 올라간 것처럼 느껴지는지 확인한다.
|
||||
- Stage 3-4에서 혼합 편대/제압 작전으로 플레이 양상이 달라지는지 확인한다.
|
||||
- Stage 5 이후부터 물량 증가가 명확하게 느껴지는지 확인한다.
|
||||
- Stage 8이 최종 침공군답게 가장 강한 물량과 화력을 보여주는지 확인한다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
@@ -0,0 +1,32 @@
|
||||
# 📜 2026-04-30 회사 대화록
|
||||
|
||||
_모든 명령·분배·산출물·대화가 시간순으로 누적됩니다. 두뇌가 자동 인덱싱·동기화합니다._
|
||||
|
||||
## [16:07:45] 👤 **사용자**
|
||||
|
||||
[모닝 브리핑] 오늘 날짜는 2026-04-30입니다. 회사 목표(goals.md)와 지금까지의 의사결정 로그를 바탕으로 오늘 우리 회사가 우선순위로 처리해야 할 작업 3가지를 결정하고, 각 작업을 적절한 에이전트에게 분배하세요.
|
||||
|
||||
## [16:28:10] 🧭 **CEO** · _작업 분배_
|
||||
|
||||
회사 목표와 로그가 초기화 상태이므로, 시장 분석을 통한 닉슈 선정 → 수익화 전략 및 KPI 도출 → 일일/주간 실행 계획 수립 순으로 3가지 우선 작업을 정의합니다.
|
||||
|
||||
**할당:**
|
||||
- 🔍 **[[Research|Research]]er**: AI/기술/콘텐츠 관련 상위 3개 시장 트렌드와 주요 경쟁 채널의 성장 패턴을 분석한 후, 우리 회사가 1개월 내 진입 가능한 최적의 1개 닉슈와 핵심 타깃 키워드 5개를 정리해 보고하세요.
|
||||
- 💰 **[[business|business]]**: re[[Search|Search]]er의 분석 결과를 기반으로 초기 수익화 모델(광고/스폰서/디지털 제품 중 1개 선택)을 제안하고, 월별 조회수·구독자·변환율 목표를 포함한 KPI 프레임워크와 가격/수익 구조를 1페이지 분량으로 작성하세요.
|
||||
- 📱 **secretary**: 리서치와 비즈니스 전략 결과를 종합해 오늘 하루의 핵심 작업 3가지를 최종 확정하고, 마감 시간·담당 에이전트·진행 상태를 명시한 데일리 브리핑과 1주일 액션 플랜을 텔레그램 보고 형식으로 출력하세요.
|
||||
|
||||
## [16:33:10] 🔍 **[[researcher|researcher]]** · _AI/기술/콘텐츠 관련 상위 3개 시장 트렌드와 주요 경쟁 채널의 성장 패턴을 분석한 후, 우리 회사가 1개_
|
||||
|
||||
⚠️ Researcher 에이전트 호출 실패: aborted
|
||||
|
||||
## [16:37:31] 👤 **사용자**
|
||||
|
||||
[자율 사이클 — 2026-04-30] 사용자가 자리를 비웠습니다. 회사 목표·각 에이전트의 개인 목표(_agents/{id}/[[goal|goal]].md)·최근 의사결정·메모리를 검토해서 지금 가장 가치 있는 단일 작업 1개를 결정하고, 적절한 1~2명 에이전트에게 분배해서 실행하세요. 같은 산출물을 반복하지 마세요 — 메모리에 비슷한 항목이 24시간 내에 있으면 다른 각도로 진전시키세요.
|
||||
|
||||
## [16:38:10] 💰 **Business** · _researcher의 분석 결과를 기반으로 초기 수익화 모델(광고/스폰서/디지털 제품 중 1개 선택)을 제안_
|
||||
|
||||
⚠️ Business 에이전트 호출 실패: aborted
|
||||
|
||||
## [16:43:10] 📱 **Secretary** · _리서치와 비즈니스 전략 결과를 종합해 오늘 하루의 핵심 작업 3가지를 최종 확정하고, 마감 시간·담당 에이전_
|
||||
|
||||
⚠️ Secretary 에이전트 호출 실패: aborted
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,43 @@
|
||||
---
|
||||
id: P-REINFORCE-WIKI-D7150244
|
||||
category: Unified
|
||||
confidence_score: 0.95
|
||||
tags: ['architecture-principles']
|
||||
last_reinforced: 2026-05-02
|
||||
---
|
||||
|
||||
# AI-Human Discussion Log
|
||||
|
||||
## Topic
|
||||
Project Chronicle Guard sidebar Designer menu and Markdown record system.
|
||||
|
||||
## User Request Summary
|
||||
The user wants a Designer menu in the sidebar and a staged implementation of a project planning, decision, and development record system.
|
||||
|
||||
## AI Questions
|
||||
|
||||
### Question
|
||||
No blocking question was asked.
|
||||
|
||||
### Reason
|
||||
The current workspace, project root, and a reasonable record location were available from local context.
|
||||
|
||||
### Impact On Decision
|
||||
The first implementation can proceed with `ConnectAI` as the active project and `docs/records/ConnectAI` as the planning record location.
|
||||
|
||||
## Main Discussion
|
||||
The feature should not replace code generation or existing agent execution. It should sit beside those features as a recording and decision support layer.
|
||||
|
||||
## Decisions
|
||||
- Use an independent `src/features/projectChronicle` module.
|
||||
- Add a sidebar Designer control similar to existing Brain and Agent controls.
|
||||
- Keep the MVP file-based and Markdown-only.
|
||||
- Do not implement full automatic transcript capture in the first stage.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Architecture]]
|
||||
* [[P-Reinforce]]
|
||||
* [[Principles]]
|
||||
* [[_system]]
|
||||
* [[decisions]]
|
||||
+57
@@ -0,0 +1,57 @@
|
||||
---
|
||||
id: P-REINFORCE-WIKI-5B04311B
|
||||
category: Unified
|
||||
confidence_score: 0.95
|
||||
tags: ['architecture-principles']
|
||||
last_reinforced: 2026-05-02
|
||||
---
|
||||
|
||||
# Development Log: Project Chronicle Guard Feedback Response
|
||||
|
||||
## Purpose
|
||||
Improve Chronicle Guard behavior after testing showed the assistant still answered like a general idea proposer instead of a project planning and record guard.
|
||||
|
||||
## Feedback Summary
|
||||
The tested response understood the broad idea, but missed key guard behaviors:
|
||||
- Project target check
|
||||
- Record path check
|
||||
- Question intent and question reasons
|
||||
- Pending decision candidates
|
||||
- Low-dependency MVP first
|
||||
- Candidate records at the end
|
||||
- Plain engineering tone
|
||||
|
||||
## Implementation Summary
|
||||
- Made Chronicle Guard context apply by default unless explicitly disabled from the webview payload.
|
||||
- Strengthened the Guard response contract for new ideas and feature requests.
|
||||
- Added required response order: summary, intent, project check, record path check, blocking questions, question reasons, direction review, MVP, later expansion, candidate records.
|
||||
- Added decision policy so unconfirmed decisions stay pending.
|
||||
- Added tone rules against inflated consulting language and premature Vector DB / relational DB / knowledge graph suggestions.
|
||||
- Extracted Guard prompt generation into `buildProjectChronicleGuardContext`.
|
||||
- Added tests that lock the most important Guard rules.
|
||||
- Added base system prompt guidance to prefer practical MVP-first answers for product and architecture discussions.
|
||||
|
||||
## Changed Files
|
||||
- `src/features/projectChronicle/guardPrompt.ts`
|
||||
- `src/features/projectChronicle/index.ts`
|
||||
- `src/sidebarProvider.ts`
|
||||
- `src/utils.ts`
|
||||
- `tests/projectChronicleGuardPrompt.test.ts`
|
||||
|
||||
## Verification
|
||||
- `./node_modules/.bin/tsc --noEmit`
|
||||
- `npm run compile`
|
||||
- `./node_modules/.bin/jest --runInBand`
|
||||
|
||||
## Result
|
||||
Chronicle Guard should now behave less like a general ideation assistant and more like a project planning, decision, and record guard.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Architecture]]
|
||||
* [[Index]]
|
||||
* [[P-Reinforce]]
|
||||
* [[Principles]]
|
||||
* [[Purpose]]
|
||||
* [[_system]]
|
||||
* [[decisions]]
|
||||
+66
@@ -0,0 +1,66 @@
|
||||
---
|
||||
id: P-REINFORCE-WIKI-D4A6E581
|
||||
category: Unified
|
||||
confidence_score: 0.95
|
||||
tags: ['architecture-principles']
|
||||
last_reinforced: 2026-05-02
|
||||
---
|
||||
|
||||
# Development Log: Project Chronicle Guard Stage 1
|
||||
|
||||
## Purpose
|
||||
Add the first stable stage of the Designer menu and Project Chronicle Guard without coupling it tightly to chat execution.
|
||||
|
||||
## Implementation Summary
|
||||
- Added an independent `src/features/projectChronicle` module.
|
||||
- Added typed project, planning, discussion, decision, development, bug, and retrospective records.
|
||||
- Added a Markdown writer with folder creation and filename collision protection.
|
||||
- Added templates for project seed files and record documents.
|
||||
- Added a Designer row in the sidebar with project selection and explicit record actions.
|
||||
- Added VS Code-side handlers for creating/selecting record projects and writing planning, development, and bug records.
|
||||
|
||||
## Architecture
|
||||
|
||||
```text
|
||||
Sidebar Designer UI
|
||||
-> Webview postMessage
|
||||
-> SidebarChatProvider handlers
|
||||
-> ProjectChronicleManager
|
||||
-> MarkdownFileWriter
|
||||
-> docs/records/{Project}/...
|
||||
```
|
||||
|
||||
## Changed Files
|
||||
- `src/features/projectChronicle/types.ts`
|
||||
- `src/features/projectChronicle/markdownFileWriter.ts`
|
||||
- `src/features/projectChronicle/templates.ts`
|
||||
- `src/features/projectChronicle/index.ts`
|
||||
- `src/sidebarProvider.ts`
|
||||
- `docs/records/ConnectAI/...`
|
||||
|
||||
## Dependency Notes
|
||||
The implementation uses only TypeScript, Node `fs`/`path`, and VS Code extension APIs already available in the project.
|
||||
|
||||
## Verification
|
||||
- `npm run compile`
|
||||
- `./node_modules/.bin/jest --runInBand`
|
||||
|
||||
## Known Limits
|
||||
- The records are generated through explicit sidebar actions.
|
||||
- Full automatic conversation analysis is not implemented in this stage.
|
||||
- Retrospective and ADR writing are available in the module, but the sidebar only exposes Plan, Dev, and Bug actions in this first pass.
|
||||
|
||||
## Next Development Notes
|
||||
- Add a richer Designer panel for ADR, discussion, and retrospective creation.
|
||||
- Capture AI question intent more directly during the conversation flow.
|
||||
- Add tests for the Project Chronicle manager.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Analysis]]
|
||||
* [[Architecture]]
|
||||
* [[Index]]
|
||||
* [[P-Reinforce]]
|
||||
* [[Principles]]
|
||||
* [[Purpose]]
|
||||
* [[Seed]]
|
||||
+62
@@ -0,0 +1,62 @@
|
||||
---
|
||||
id: P-REINFORCE-WIKI-A3F62F03
|
||||
category: Unified
|
||||
confidence_score: 0.95
|
||||
tags: ['architecture-principles']
|
||||
last_reinforced: 2026-05-02
|
||||
---
|
||||
|
||||
# Development Log: Project Chronicle Guard Stage 2
|
||||
|
||||
## Purpose
|
||||
Expand the Designer menu from basic Plan/Dev/Bug writing into a fuller MVP record writer.
|
||||
|
||||
## Implementation Summary
|
||||
- Reworked the Designer sidebar controls into a project selector plus a record type selector.
|
||||
- Added explicit write flows for discussion, decision, and retrospective records.
|
||||
- Preserved the existing planning, development, and bug writers.
|
||||
- Added question intent capture in the discussion writer through optional prompts.
|
||||
- Added ADR numbering for decision records and timeline updates for every record type.
|
||||
- Expanded tests to verify all major record categories are written to their expected folders.
|
||||
|
||||
## Design Adjustment
|
||||
The first pass exposed separate buttons for Plan, Dev, and Bug. Stage 2 changes this to a more scalable pattern:
|
||||
|
||||
```text
|
||||
Designer Project Selector
|
||||
Record Type Selector
|
||||
Write / Open / Add actions
|
||||
```
|
||||
|
||||
This keeps the sidebar usable as more record types are added.
|
||||
|
||||
## Changed Files
|
||||
- `src/sidebarProvider.ts`
|
||||
- `tests/projectChronicle.test.ts`
|
||||
- `docs/records/ConnectAI/development/2026-05-02_project-chronicle-guard_stage-2_implementation.md`
|
||||
|
||||
## Verification
|
||||
- `./node_modules/.bin/tsc --noEmit`
|
||||
- `npm run compile`
|
||||
- `./node_modules/.bin/jest --runInBand`
|
||||
|
||||
## Result
|
||||
The Designer menu can now create the MVP record types:
|
||||
- Planning
|
||||
- Discussion
|
||||
- Decision
|
||||
- Development
|
||||
- Bug
|
||||
- Retrospective
|
||||
|
||||
## Next Development Notes
|
||||
- Add a dedicated Designer panel for editing richer record content before writing.
|
||||
- Add automatic conversation event capture so records can be generated with less manual input.
|
||||
- Add settings for default record detail level and automatic timeline behavior.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Architecture]]
|
||||
* [[P-Reinforce]]
|
||||
* [[Principles]]
|
||||
* [[Purpose]]
|
||||
+62
@@ -0,0 +1,62 @@
|
||||
---
|
||||
id: P-REINFORCE-WIKI-718C7EBB
|
||||
category: Unified
|
||||
confidence_score: 0.95
|
||||
tags: ['architecture-principles']
|
||||
last_reinforced: 2026-05-02
|
||||
---
|
||||
|
||||
# Development Log: Project Chronicle Guard Stages 3 to 5
|
||||
|
||||
## Purpose
|
||||
Complete the remaining MVP support around Designer mode, record browsing, and project configuration persistence.
|
||||
|
||||
## Stage 3: Chronicle Guard Mode
|
||||
- Added a `Guard` toggle in the sidebar header.
|
||||
- When enabled, active Designer project context is injected into the agent system context.
|
||||
- The guard context asks the assistant to summarize requests, infer intent, explain blocking questions, identify decisions, and name records that should be written.
|
||||
- The mode is restored through webview state.
|
||||
|
||||
## Stage 4: Record Browser
|
||||
- Added a record list selector for generated Chronicle Markdown files.
|
||||
- Added refresh and open actions for selected records.
|
||||
- Added record listing to `ProjectChronicleManager`.
|
||||
- Added path validation before opening selected Markdown records.
|
||||
|
||||
## Stage 5: Project Config File
|
||||
- Added `chronicle.config.json` generation under each project record root.
|
||||
- The config file stores project id, project name, root, record root, description, purpose, detail level, and timestamps.
|
||||
- This gives the record folder its own portable project metadata, independent of VS Code global state.
|
||||
|
||||
## Changed Files
|
||||
- `src/agent.ts`
|
||||
- `src/sidebarProvider.ts`
|
||||
- `src/features/projectChronicle/index.ts`
|
||||
- `src/features/projectChronicle/types.ts`
|
||||
- `tests/projectChronicle.test.ts`
|
||||
|
||||
## Verification
|
||||
- `./node_modules/.bin/tsc --noEmit`
|
||||
- `npm run compile`
|
||||
- `./node_modules/.bin/jest --runInBand`
|
||||
|
||||
## Result
|
||||
The staged MVP is now functionally complete:
|
||||
- Select or create Designer project
|
||||
- Generate project record structure
|
||||
- Persist project config
|
||||
- Enable Chronicle Guard response mode
|
||||
- Write all MVP record types
|
||||
- Browse and open generated Markdown records
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Architecture]]
|
||||
* [[Browser]]
|
||||
* [[Index]]
|
||||
* [[P-Reinforce]]
|
||||
* [[Principles]]
|
||||
* [[Purpose]]
|
||||
* [[State]]
|
||||
* [[_system]]
|
||||
* [[decisions]]
|
||||
+38
@@ -0,0 +1,38 @@
|
||||
---
|
||||
id: P-REINFORCE-WIKI-EC4DA38B
|
||||
category: Unified
|
||||
confidence_score: 0.95
|
||||
tags: ['architecture-principles']
|
||||
last_reinforced: 2026-05-02
|
||||
---
|
||||
|
||||
# Development Log: Second Brain Trace Collapsible UI
|
||||
|
||||
## Purpose
|
||||
Reduce visual noise from Second Brain Trace details while keeping the evidence available when the user wants to inspect it.
|
||||
|
||||
## Implementation Summary
|
||||
- Wrapped Second Brain Trace output in a collapsed HTML `<details>` block.
|
||||
- Added a compact summary line showing usage status and note counts.
|
||||
- Kept detailed referenced notes, unused notes, grounding metrics, and debug JSON inside the expanded section.
|
||||
- Updated tests to verify the collapsible structure is rendered.
|
||||
|
||||
## Changed Files
|
||||
- `src/features/secondBrainTrace.ts`
|
||||
- `tests/secondBrainTrace.test.ts`
|
||||
|
||||
## Verification
|
||||
- `./node_modules/.bin/tsc --noEmit`
|
||||
- `npm run compile`
|
||||
- `./node_modules/.bin/jest --runInBand`
|
||||
|
||||
## Result
|
||||
Trace evidence is still available, but it no longer dominates every answer by default.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Architecture]]
|
||||
* [[Noise]]
|
||||
* [[P-Reinforce]]
|
||||
* [[Principles]]
|
||||
* [[Purpose]]
|
||||
+50
@@ -0,0 +1,50 @@
|
||||
---
|
||||
id: P-REINFORCE-WIKI-18722064
|
||||
category: Unified
|
||||
confidence_score: 0.95
|
||||
tags: ['architecture-principles']
|
||||
last_reinforced: 2026-05-02
|
||||
---
|
||||
|
||||
# Development Log: Second Brain Trace Mode
|
||||
|
||||
## Purpose
|
||||
Make Second Brain usage visible and testable in AI answers.
|
||||
|
||||
## Implementation Summary
|
||||
- Added `src/features/secondBrainTrace.ts`.
|
||||
- Added trace scoring over active Second Brain Markdown files.
|
||||
- Added user-facing trace Markdown with usage status, referenced documents, unused documents, and grounding metrics.
|
||||
- Added debug JSON output when debug mode is enabled.
|
||||
- Added Trace and Dbg sidebar buttons.
|
||||
- Connected trace context into `AgentExecutor`.
|
||||
- Added tests for retrieval, rendering, debug JSON, and no-use cases.
|
||||
|
||||
## Changed Files
|
||||
- `src/features/secondBrainTrace.ts`
|
||||
- `src/agent.ts`
|
||||
- `src/sidebarProvider.ts`
|
||||
- `tests/secondBrainTrace.test.ts`
|
||||
- `docs/records/ConnectAI/planning/2026-05-02_second-brain-trace-mode.md`
|
||||
- `docs/records/ConnectAI/development/2026-05-02_second-brain-trace-mode_implementation.md`
|
||||
|
||||
## Verification
|
||||
- `./node_modules/.bin/tsc --noEmit`
|
||||
- `npm run compile`
|
||||
- `./node_modules/.bin/jest --runInBand`
|
||||
|
||||
## Result
|
||||
When Trace mode is on, answers can now include:
|
||||
- 2nd Brain usage status
|
||||
- Reason for use or non-use
|
||||
- Referenced note paths and excerpts
|
||||
- Searched but unused notes
|
||||
- Retrieval and grounding metrics
|
||||
- Optional debug JSON
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Architecture]]
|
||||
* [[P-Reinforce]]
|
||||
* [[Principles]]
|
||||
* [[Purpose]]
|
||||
@@ -0,0 +1,69 @@
|
||||
---
|
||||
category: Unified
|
||||
tags: [category-index, project_logs]
|
||||
title: Project Logs Directory
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
# Project Logs Directory
|
||||
|
||||
이 문서는 `Project_Logs` 카테고리에 속한 모든 지식 문서들의 목록을 제공합니다.
|
||||
|
||||
## 📄 문서 목록
|
||||
- [[README|2026-04-15]] : [[README|2026-04-15]]
|
||||
- [[2026-04-21-Engine-Stability-and-Optimization]] : Engine Stability and Optimization (2026-04-21)
|
||||
- [[2026-04-21-Implementation-and-Architecture-Report]] : Skybound Implementation and Architecture Report (V10.5)
|
||||
- [[2026-04-21-Project-Report-V11.5-Combat-and-UI-Recovery]] : Project Report V11.5: Combat and UI Recovery (2026-04-21)
|
||||
- [[2026-04-21-UX-Dopamine-Feedback-Upgrade]] : UX and Dopamine Feedback Upgrade (V10.0)
|
||||
- [[2026-04-21_Stability_and_Optimization_Report]] : ⚡ Skybound: Stability & [[Optimization|Optimization]] Report (2026-04-21)
|
||||
- [[2026-04-22_Boss_Battle_System_Implementation]] : [TECH-REPORT] Skybound Boss Battle Architecture (v1.0)
|
||||
- [[2026-04-22_Boss_Spawn_Logic_Fix]] : 📝 [Technical Report] 보스 스폰 시스템 안정화 및 AI 교전 로직 개선
|
||||
- [[2026-04-22_Engine_Logic_Optimization_Report]] : ⚙️ Engine Logic Optimization & Modernization
|
||||
- [[2026-04-22_Engine_Stability_Audit]] : 🔍 Skybound 엔진 구조 정밀 감사 보고서 (V12.1)
|
||||
- [[2026-04-23_Engine_Stabilization_Report]] : ISSUE REPORT: [v13.1] Engine Stabilization & Tactical Boundary Overhaul
|
||||
- [[2026-04-23_Post-Mortem_Loot_Rebalance]] : POST-MORTEM: Skybound Meta-Game Stabilization & Loot Economy Overhaul (2026-04-23)
|
||||
- [[2026-04-24-Skybound_Code_Structure_Audit_and_Stabilization_Plan]] : Skybound Code Structure Audit and Stabilization Plan
|
||||
- [[2026-04-24-Skybound_Final_Stylized_Casual_Magitech_Redirection]] : Skybound Final Stylized Casual Magitech Redirection
|
||||
- [[2026-04-24-Skybound_HUD_and_TAC_LevelUp_Stylized_Casual_Magitech_Fix]] : Skybound HUD and TAC Level Up Stylized Casual Magitech Fix
|
||||
- [[2026-04-24-Skybound_Nova_Burst_Icon_and_Effect_Fix]] : Skybound Nova Burst Icon and Effect Fix
|
||||
- [[2026-04-24-Skybound_Particle_and_Supply_Readability_Fix]] : Skybound Particle and Supply Readability Fix
|
||||
- [[2026-04-24-Skybound_Semirealistic_Magitech_Fantasy_Redirection]] : Skybound Semirealistic Magitech Fantasy Redirection
|
||||
- [[2026-04-24-Skybound_Stylized_Casual_Magitech_Art_Pack]] : Skybound Semirealistic Magitech Fantasy Art Pack
|
||||
- [[2026-04-24-Skybound_Stylized_Casual_Magitech_Ingame_Asset_Fix]] : Skybound Stylized Casual Magitech Ingame Asset Fix
|
||||
- [[2026-04-24-Skybound_Survivor_Like_Balance_Curve_Pass]] : Skybound Survivor-Like Balance Curve Pass
|
||||
- [[2026-04-25-Datacollector_Auto_Resume_After_Reauth_Fix]] : Datacollector - 인증 복구 후 자동 재개 상태 전환 수정
|
||||
- [[2026-04-25-Datacollector_Bridge_Connection_Refused_Run_Script_Fix]] : Datacollector Bridge Connection Refused Run Script Fix
|
||||
- [[2026-04-25-Datacollector_Codebase_Structure_Review_and_Initial_Risk_Assessment]] : Datacollector Codebase Structure Review and Initial Risk [[Assessment|Assessment]]
|
||||
- [[2026-04-25-Datacollector_Engine_Processed_Count_and_Stalled_Loop_Guard]] : Datacollector - processed 카운터 정체 및 엔진 루프 정지 감시 보강
|
||||
- [[2026-04-25-Datacollector_Local_Wiki_Save_Only_Output_Mode]] : Datacollector Local Wiki Save Only Output Mode
|
||||
- [[2026-04-25-Datacollector_Mac_Windows_Launcher_Scripts]] : Datacollector Mac Windows Launcher [[Scripts|Scripts]]
|
||||
- [[2026-04-25-Datacollector_NotebookLM_Auth_Browser_and_Stale_Env_Cookie_Fix]] : Datacollector - NotebookLM 인증 브라우저 유지 및 오래된 .env 쿠키 우선순위 문제 해결
|
||||
- [[2026-04-25-Datacollector_NotebookLM_Automatic_Auth_Recovery]] : Datacollector NotebookLM Automatic Auth Recovery
|
||||
- [[2026-04-25-Datacollector_NotebookLM_Automatic_Reauth_Verification_and_Lock]] : Datacollector - NotebookLM 자동 재인증 검증 강화 및 동시 복구 잠금
|
||||
- [[2026-04-25-Datacollector_NotebookLM_Connection_Guard_and_MCP_Restart_Fix]] : Datacollector NotebookLM Connection Guard and MCP Restart Fix
|
||||
- [[2026-04-25-Datacollector_NotebookLM_Progress_Visibility_and_Auth_Diagnosis]] : Datacollector NotebookLM Progress Visibility and Auth Diagnosis
|
||||
- [[2026-04-25-Skybound_Core_Gameplay_Rebalance_and_Purpose_Reset]] : Skybound Core Gameplay Rebalance and Purpose Reset
|
||||
- [[2026-04-25-Skybound_Player_Airframe_and_8Stage_Boss_Continuity_Rework]] : Skybound Player Airframe and 8 Stage Boss Continuity Rework
|
||||
- [[2026-04-25-Skybound_Skill_Concept_and_Hangar_Layout_Overlap_Fix]] : Skybound Skill Concept and Hangar Layout Overlap Fix
|
||||
- [[2026-04-25-Skybound_TacExp_DirectKill_and_UI_Productization_Pass]] : Skybound Tac EXP Direct Kill and UI Productization Pass
|
||||
- [[2026-04-25-Skybound_Vampire_Survivors_Loop_and_Stage_Curve_Preparation]] : Skybound Vampire Survivors Loop and Stage Curve Preparation
|
||||
- [[2026-04-26-Skybound_Enemy_Motion_Damage_Pressure_and_Projectile_Visual_Pass]] : Skybound Enemy Motion Damage Pressure and Projectile Visual Pass
|
||||
- [[2026-04-26-Skybound_HP_Scarcity_and_Module_Cache_Rewards]] : Skybound HP Scarcity and Module Cache Rewards
|
||||
- [[2026-04-26-Skybound_Invasion_Response_Stage_Difficulty_Curve]] : Skybound Invasion Response Stage Difficulty Curve
|
||||
- [[2026-04-26-Skybound_Low_Level_First_Upgrade_Offer_Balance]] : Skybound Low Level First Upgrade Offer Balance
|
||||
- [[2026-04-26-Skybound_Miniboss_Treasure_Cache_Reward_Loop]] : Skybound Miniboss Treasure Cache Reward Loop
|
||||
- [[2026-04-26-Skybound_Player_Sprite_Path_Warning_Fix]] : Skybound Player Sprite Path Warning Fix
|
||||
- [[2026-04-26-Skybound_Reward_Card_Clarity_and_Command_Cache_UI]] : Skybound Reward Card Clarity and Command Cache UI
|
||||
- [[2026-04-26-Skybound_Skill_Slot_Limit_Weapon5_Passive5]] : Skybound Skill Slot Limit Weapon 5 Passive 5
|
||||
- [[2026-04-26-Skybound_Skip_Upgrade_and_Weapon_Transform_Reconfiguration]] : Skybound Skip Upgrade and Weapon Transform Reconfiguration
|
||||
- [[2026-04-26-Skybound_Stage1_to_3_Playtest_Balance_Bomb_and_Visual_Diversity_Pass]] : Skybound Stage 1 to 3 Playtest Balance Bomb and Visual Diversity Pass
|
||||
- [[2026-04-26-Skybound_Stage_Miniboss_Pattern_Differentiation]] : Skybound Stage Miniboss Pattern Differentiation
|
||||
- [[2026-04-30]] : 📜 2026-04-30 회사 대화록
|
||||
- [[2026-05-01]] : 📜 2026-05-01 회사 대화록
|
||||
- [[2026-05-02_project-chronicle-guard]] : AI-Human Discussion Log
|
||||
- [[2026-05-02_project-chronicle-guard_feedback-response]] : Development Log: Project Chronicle Guard Feedback Response
|
||||
- [[2026-05-02_project-chronicle-guard_stage-1_implementation]] : Development Log: Project Chronicle Guard Stage 1
|
||||
- [[2026-05-02_project-chronicle-guard_stage-2_implementation]] : Development Log: Project Chronicle Guard Stage 2
|
||||
- [[2026-05-02_project-chronicle-guard_stage-3-to-5_implementation]] : Development Log: Project Chronicle Guard Stages 3 to 5
|
||||
- [[2026-05-02_second-brain-trace-collapsible-ui]] : Development Log: Second Brain Trace Collapsible UI
|
||||
- [[2026-05-02_second-brain-trace-mode_implementation]] : Development Log: Second Brain Trace Mode
|
||||
Reference in New Issue
Block a user