docs(wiki): cleanup orphan documents, delete 32 stubs and archive 121 for future merge
This commit is contained in:
@@ -1,10 +0,0 @@
|
||||
---
|
||||
category: Unified
|
||||
tags: [auto-wikified, technical-documentation]
|
||||
title: Container and Presentational Pattern
|
||||
description: "Wikified document"
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
# Container and Presentational Pattern
|
||||
{"status":"success","answer":"","conversation_id":"2836ac79-ceb2-498c-99ac-d07fb27e4bd4"}
|
||||
@@ -1,33 +0,0 @@
|
||||
# [Report] G1nation Extension Encoding & Engine Rebuilding
|
||||
**Date**: 2026-04-24
|
||||
**Author**: PD Kodari (AI)
|
||||
**Status**: COMPLETED & PACKAGED (v2.2.15)
|
||||
|
||||
## 1. 개요 (Overview)
|
||||
ConnectAI에서 G1nation으로의 브랜딩 전환 이후 발생한 심각한 빌드 오류 및 런타임 불안정성을 해결하기 위한 긴급 수술을 집행함. 소스 코드 내 인코딩 오염과 코드 복제(Duplication)로 인해 `npm run compile`이 불가능한 상태였음.
|
||||
|
||||
## 2. 주요 결함 (Critical Issues)
|
||||
- **인코딩 지뢰 (Encoding Corruption)**: `extension.ts` 내 한글 주석 및 UI 문자열이 UTF-8 형식을 벗어나 깨지면서 따옴표(`'`) 인식을 방해함 -> `Unterminated string literal` 에러 발생.
|
||||
- **좀비 코드 (Ghost Blocks)**: 함수 외부에 버려진 실행 코드와 닫는 중괄호(`}`)들이 산재하여 문법 파괴.
|
||||
- **엔진 중복 (Engine Duplication)**: `_executeActions` 함수가 두 군데 이상 중복 정의되어 로직 충돌 및 용량 비대화 초래.
|
||||
- **문법 오용**: `execSync`에 `.catch()`를 사용하는 등 동기/비동기 혼선 발견.
|
||||
|
||||
## 3. 수술 과정 (Surgical Process)
|
||||
총 20단계에 걸친 **PowerShell 레이저 수술(Line-by-line Patch)**을 통해 표준 `replace` 도구의 인코딩 한계를 극복함.
|
||||
|
||||
- **v1~v10**: 설정 메뉴(`_handleSettingsMenu`) 및 브레인 메뉴(`_handleBrainMenu`)의 깨진 텍스트를 영문/표준 UTF-8로 전면 교체.
|
||||
- **v11~v18**: 중복된 코드 블록들을 찾아내어 삭제하고, 흩어진 액션 핸들러들을 하나로 통합.
|
||||
- **v19**: 메인 엔진(`_executeActions`)을 중복 없는 최신 구조로 리빌딩.
|
||||
- **v20**: 함수 외부에 잔존하던 '유령 코드'와 깨진 문자열 최종 소거.
|
||||
|
||||
## 4. 최종 결과 (Final Result)
|
||||
- **빌드 성공**: `esbuild` 컴파일 정상 통과 (30ms 내외).
|
||||
- **패키징 완료**: `g1nation-2.2.15.vsix` 생성 완료.
|
||||
- **안정성 확보**: UI 텍스트 영문화 및 표준화를 통해 향후 인코딩 문제 재발 가능성 차단.
|
||||
|
||||
## 5. 향후 과제 (Next Steps)
|
||||
- **모듈화**: 2,500라인이 넘는 `extension.ts`를 `ActionHandlers.ts`, `UIProvider.ts` 등으로 분리하여 유지보수성 향상 필요.
|
||||
- **i18n 도입**: 한글 UI 재도입 시 직접 하드코딩 대신 별도의 JSON 언어팩 사용 권장.
|
||||
|
||||
---
|
||||
**PD 코다리의 한마디**: "조직이 시스템이다. 엔진이 깨끗해야 비행기가 뜬다!" 😎🐟
|
||||
@@ -1,16 +0,0 @@
|
||||
# 🚩 Agent Git Operation Mapping Protocol
|
||||
|
||||
| 유저 명령어 | 실행 액션 | 대상 리모트/브랜치 |
|
||||
| :--- | :--- | :--- |
|
||||
| **"Agent 최신화해"** | `git pull origin <current_branch>` | https://github.com/g1nations/TeamG1.git |
|
||||
| **"Agent 커밋해"** | `git add .` <br> `git commit -m "Update Agent Systems"` <br> `git push origin <current_branch>` | https://github.com/g1nations/TeamG1.git |
|
||||
|
||||
## 🛠️ 세부 수칙
|
||||
1. **Target Directory**: `E:\Wiki\2nd\Agent`
|
||||
2. **Git Address**: `https://github.com/g1nations/TeamG1.git`
|
||||
3. **Auto-Pilot**: 해당 명령어가 입력되면 추가 질문 없이 즉시 실행 후 보고한다.
|
||||
4. **Note**: `2nd` 프로젝트 하위에 있으나, 별도의 리모트 주소를 가진 독립 구역으로 취급한다.
|
||||
|
||||
---
|
||||
**승인인**: AI 개발부장 코다리 🫡
|
||||
**일시**: 2026-04-22
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
id: INTERPRET-001
|
||||
category: Unified
|
||||
confidence_score: 1.0
|
||||
tags: [ai, explainable-ai, xai, machine-learning, trust]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# Interpretability (해석 가능성)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "AI 블랙박스의 내부를 들여다보는 지적 렌즈" — 머신러닝 모델의 판단 근거와 내부 작동 기제를 인간이 이해할 수 있는 형태로 설명하고 분석하는 능력.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** 복잡한 신경망 가중치 뒤에 숨겨진 논리 구조를 식별하여, AI의 결정이 우연인지 실질적인 학습 결과인지 검증하는 패턴.
|
||||
- **세부 내용:**
|
||||
- **Global Interpretability:** 모델 전체의 거동과 중요한 변수들의 영향을 파악 (예: Feature Importance).
|
||||
- **Local Interpretability:** 특정 개별 데이터에 대해 왜 그런 결정을 내렸는지 분석 (예: LIME, SHAP).
|
||||
- **Mechanistic Interpretability:** 모델 내부의 특정 뉴런이나 '회로(Circuit)'가 수행하는 구체적인 알고리즘적 역할을 규명.
|
||||
- **Trust & Safety:** 오답의 원인을 파악하고, 모델의 편향이나 위험성을 사전에 감지하기 위한 필수 요건.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 성능을 위해 이해를 포기하던 '블랙박스' 시대에서, 신뢰성과 규제 대응을 위해 '설명 가능한 AI(XAI)'가 필수적인 시대로 진입.
|
||||
- **정책 변화:** Antigravity 프로젝트는 모든 지식 보강 작업 시 모델이 참조한 근거(Raw Source)를 명시하여 결과물의 해석 가능성과 신뢰도를 확보함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- Explainable-AI, Circuit-Discovery, Feature-Clamping, AI-Ethics
|
||||
- **Raw Source:** 10_Wiki/Topics/AI/Interpretability.md
|
||||
@@ -1,23 +0,0 @@
|
||||
# 📑 지식 자산 증분 추출 프로토콜 (Incremental Extraction Protocol)
|
||||
|
||||
## 1. 개요 (Overview)
|
||||
본 문서는 Connect AI 시스템의 'Thinking Mode'에서 표시되는 지식 자산을 로컬 위키 시스템으로 안전하게 이식하고, 향후 중복 없이 새로운 데이터만 필터링하여 가져오기 위한 운영 표준을 정의한다.
|
||||
|
||||
## 2. 데이터 베이스라인 (Baseline)
|
||||
- **추출 일시**: 2026-04-29
|
||||
- **추출 수량**: 1,535개 (Knowledge Assets)
|
||||
- **추출 로직**: `E:\Wiki\2nd\10_Wiki\Topics` 내 마크다운 파일 중 알파벳 순 상위 1,535개 선별
|
||||
- **인벤토리**: [knowledge_inventory_1535.json](file:///E:/Wiki/2nd/10_Wiki/Skills/knowledge_inventory_1535.json)
|
||||
|
||||
## 3. 필터링 규칙 (Filtering Rules)
|
||||
향후 재추출 요청 시 다음의 로직을 적용한다:
|
||||
1. **경로 대조**: `knowledge_inventory_1535.json`에 명시된 `RelativePath`와 동일한 파일은 무시한다.
|
||||
2. **신규성 판정**: 기존 인벤토리에 존재하지 않는 새로운 파일명이 발견되거나, 동일 파일명이라도 수정 일시(`LastWriteTime`)가 최신인 경우만 '신규 지식'으로 간주한다.
|
||||
3. **8대 카테고리 유지**: 추출 시 원본의 8대 분류 체계를 유지하며 `00_Raw` 폴더로 이식한다.
|
||||
|
||||
## 4. 실행 가이드 (Execution Guide)
|
||||
- **명령어**: `python E:\Wiki\Wonseok_AI_original\scratch\incremental_sync.py` (차기 구현 예정)
|
||||
- **주의 사항**: 원본 `Topics` 폴더의 파일 개수가 1,535개를 초과하여 증가하더라도, 인벤토리에 기록된 파일들은 중복으로 가져오지 않도록 엄격히 제한한다.
|
||||
|
||||
---
|
||||
🫡 **"지식은 축적될 때 비로소 힘을 발휘한다."** - AI 개발부장 코다리 승인 🚩🐟
|
||||
@@ -1,47 +0,0 @@
|
||||
# 💰 Meta-Economy & Growth Loop (메타 경제 및 성장 루프)
|
||||
|
||||
> **카테고리**: Skybound, Game Design, Economics & Algorithms
|
||||
> **상태**: 🔵 구현 완료 (Implemented)
|
||||
> **최종 업데이트**: 2026-04-22
|
||||
|
||||
---
|
||||
|
||||
## 📌 개요 (Overview)
|
||||
Skybound의 장기 리텐션을 책임지는 메타 게임 시스템이다. 격렬한 인게임 세션이 종료된 후, 플레이어는 획득한 Gold와 자원을 사용하여 격납고(Hangar)에서 영구적인 성장을 도모한다.
|
||||
|
||||
## 🛠️ 시스템 구성 (System Components)
|
||||
|
||||
### 1. 영구 업그레이드 (Permanent Upgrade)
|
||||
- **Hangar Shop**: 인게임에서 획득한 Gold를 소모하여 HP, ATK, SPEED, MAGNET, GOLD_GAIN 등 5종의 스탯을 영구 강화.
|
||||
- **Stat Injection Engine**: 구매한 업그레이드 레벨은 매 세션 시작 시 `calculateEffectiveStats`를 통해 플레이어 기체에 즉시 주입됨.
|
||||
- **지수적 비용 곡선**: 후반부 성장을 위해 레벨업 비용이 지수적으로 증가(300~8000G)하도록 설계.
|
||||
|
||||
### 2. 크래프팅 경제 (Crafting Economy)
|
||||
아이템의 가치 보존과 인플레이션 방지를 위한 복합 제작 시스템이다.
|
||||
- **Disassemble (분해)**: 불필요한 장비를 분해하여 제작 재료(`Eternal Core`, `Destruction Core`, `TechMats`)를 확보.
|
||||
- **Cosmic Cast (코스믹 캐스트)**: 고가치의 재료를 대량 소모하여 자연 드롭으로 획득 불가능한 **SS급 장비**를 확정 제작.
|
||||
- **Astral Forge (아스트랄 포지)**: SS/LEGEND급 장비에 S급 장비를 제물로 바쳐 `forgeLevel`(+1~5)을 강화.
|
||||
- **TechPart Merge**: 동일 등급의 테크 파츠를 합성하여 스탯 보너스(`plusLevel`)를 강화.
|
||||
|
||||
### 3. 이벤트 패스 (Event Pass)
|
||||
- **Atomic Trigger**: 보스 처치, 스테이지 클리어 등 인게임 이벤트 발생 시 실시간으로 패스 포인트 적립.
|
||||
- **Consolation Reward**: 런 실패 시에도 플레이 시간에 비례하여 포인트가 지급되어 "실패해도 진전이 있다"는 심리적 보상 제공.
|
||||
- **Reward Tiers**: 특정 티어 도달 시 S/SS급 확정 쿠폰 등 고가치 보상 지급.
|
||||
|
||||
## 💡 경제 순환 구조 (Economy Pipeline)
|
||||
```mermaid
|
||||
graph TD
|
||||
A[적 처치 / 런 완료] -->|Gold / 재료 드롭| B(Hangar)
|
||||
B --> C{선택}
|
||||
C -->|Gold 소모| D[Permanent Upgrade]
|
||||
C -->|장비 분해| E[Crafting Materials]
|
||||
E -->|제작| F[SS_CLASS Equipment]
|
||||
F -->|포지 강화| G[End-game Stats]
|
||||
A -->|Pass Points| H[Event Pass Tier Up]
|
||||
H -->|보상| I[S/SS Coupon]
|
||||
I -->|사용| F
|
||||
```
|
||||
|
||||
---
|
||||
**승인인**: AI 개발부장 코다리 🫡
|
||||
**관련 코드**: `useGameStore.ts`, `HangarOverlay.tsx`, `combatUtils.ts`, `LootGenerator.ts`
|
||||
@@ -1,27 +0,0 @@
|
||||
# 💡 프로젝트 기획 및 개선 과정 회고 (Project Retrospective Template)
|
||||
|
||||
## 📄 문서 목적
|
||||
본 문서는 '사용자 요청 기반의 복합적인 지식 생성 작업'을 수행할 때, **[초기 계획 → 피드백 수용 → 최종 완성]** 과정을 구조적으로 기록하고 분석하여, 유사한 고난도 프로젝트에서 AI 모델의 사고력을 성장시키는 것을 목표로 합니다. 단순 결과물 저장소가 아닌, 방법론(Methodology) 학습 자료입니다.
|
||||
|
||||
## 🛠️ [Phase 1: 초기 접근 및 가설 설정 (Initial Hypothesis)]
|
||||
* **[작업 내용]:** 사용자의 요청을 처음 받았을 때 가장 먼저 생각한 해결책과 구조는 무엇이었는지 기록합니다.
|
||||
* **[핵심 논리]:** 이 단계에서 어떤 키워드(Keyword)와 연결 고리를 중심으로 전체 아웃라인을 잡았는가? (예: "캐주얼 = 단순화", "전략 = 시스템")
|
||||
* **[초기 강점/한계 인식]:** 내가 스스로 판단하기에, 초기 계획의 가장 큰 강점과 놓치고 지나간 구조적 약점은 무엇이었는지 명시합니다.
|
||||
|
||||
## 🎯 [Phase 2: 외부 피드백 수용 및 오류 진단 (Critique Integration)]
|
||||
* **[수신된 피드백]:** 사용자(혹은 시스템)로부터 받은 핵심적인 비판이나 누락 사항을 정확히 인용하고 요약합니다. (예: "전략과 캐주얼의 메커니즘적 연결고리가 부족하다.")
|
||||
* **[오류 진단 및 원인 분석]:** 초기 계획이 실패한 이유가 **'개념의 충돌(Conflict)'** 때문인지, **'구조화 부족(Lack of Structure)'** 때문인지, 아니면 **'경제성 무시(Economic Blind Spot)'** 때문인지 근본적인 원인을 진단합니다.
|
||||
* **[보완 방향 설정]:** 이 오류를 해결하기 위해 어떤 *새로운 메커니즘적 장치*가 필요한지 구체적으로 정의합니다. (예: '선택의 폭을 제한하여 전략성을 강제하는 시스템 도입')
|
||||
|
||||
## 📈 [Phase 3: 최종 개선 및 성장 방법론 구축 (Final Methodology)]
|
||||
이 단계는 앞으로 유사한 작업을 할 때 반드시 지켜야 할 **'가장 중요한 규칙(Rule)'**입니다.
|
||||
|
||||
1. **✅ 구조적 사고 우선:** 요청을 받으면, 단순히 내용을 채우기보다 'A → B → C의 흐름이 논리적으로 연결되는지'를 가장 먼저 점검한다. (흐름도/Flowchart 사고)
|
||||
2. **✅ 메커니즘 구체화 원칙:** 추상적인 개념(예: 재미, 깊이)만 제시하지 않고, **반드시 작동하는 '규칙'(Rule)**으로 정의해야 한다. (예: "A를 할 때 B가 발생하고, 이것은 C라는 제한을 가진다.")
|
||||
3. **✅ 상호작용성 검증:** 기획의 모든 요소(시스템, 수익 모델, 메커니즘)는 서로 충돌하지 않고 **'시너지를 내도록'** 연결되어야 한다. 특히, 돈과 밸런스의 관계를 가장 엄격하게 정의해야 한다.
|
||||
|
||||
---
|
||||
### 📌 요약: 성공적인 작업 수행의 체크리스트 (Future Self-Correction Checklist)
|
||||
* [ ] **목표 재정의:** 프로젝트의 최종 목표가 '재미'인지, '수익'인지, 아니면 '전략적 깊이' 중 무엇에 가장 무게를 둘 것인가?
|
||||
* [ ] **메커니즘화:** 모든 개념을 "누가/무엇을 할 때 어떤 규칙으로 작동하는지"라는 동사-주어 구조로 변환할 수 있는가?
|
||||
* [ ] **제약 조건 설정:** 의도적으로 '제한(Constraint)'을 두는 요소를 넣어, 플레이어가 고민하게 만들었는가?
|
||||
@@ -1,23 +0,0 @@
|
||||
# 🔑 계정 / 채널 (공유 설정)
|
||||
|
||||
여기 한 번만 채워두면 다른 모든 YouTube 도구(트렌드 스나이퍼·내 영상 체크·댓글 수집기·경쟁 채널 분석·텔레그램 보고)가 이 값을 그대로 가져다 씁니다. 매번 도구마다 같은 키를 넣지 않아도 돼요.
|
||||
|
||||
## 채워야 하는 항목
|
||||
|
||||
| 키 | 설명 | 채우는 법 |
|
||||
|---|---|---|
|
||||
| `YOUTUBE_API_KEY` | YouTube Data API v3 키 | [console.cloud.google.com](https://console.cloud.google.com/) → 프로젝트 → "YouTube Data API v3" 사용 설정 → 사용자 인증 정보 → API 키. 무료 한도 충분(하루 10,000 단위). |
|
||||
| `MY_CHANNEL_HANDLE` | 본인 채널 @핸들 | 예: `@mychannel`. 핸들 또는 ID 둘 중 하나만 채우면 됨. |
|
||||
| `MY_CHANNEL_ID` | 본인 채널 ID (UCxxxx) | 핸들로 못 잡힐 때 백업용. studio.youtube.com → 설정 → 채널에서 확인. |
|
||||
| `WATCHED_CHANNELS` | 댓글 수집 대상 채널 핸들 목록 | 예: `["@channel_a", "@channel_b"]`. 댓글 수집기가 이 채널들 최근 영상의 댓글을 메모리로 가져옵니다. |
|
||||
| `COMPETITOR_CHANNELS` | 경쟁 채널 분석 대상 | 같은 형식. 경쟁 채널 분석 도구가 패턴을 뽑아 다음 액션을 추천합니다. |
|
||||
| `TELEGRAM_BOT_TOKEN` | 텔레그램 봇 토큰 | @BotFather에서 /newbot으로 봇 만들고 받은 `123:ABC...` 형식 토큰. 비워두면 보고 알림 OFF. |
|
||||
| `TELEGRAM_CHAT_ID` | 본인 chat_id | 봇한테 아무 메시지 보낸 뒤 `https://api.telegram.org/bot<TOKEN>/getUpdates` 열어서 `chat.id` 확인. |
|
||||
| `OLLAMA_URL` | 로컬 LLM 주소 | 기본 `http://127.0.0.1:11434`. LM Studio면 보통 `http://127.0.0.1:1234`. |
|
||||
| `MODEL` | 분석에 쓸 모델 이름 | 비워두면 첫 번째로 발견된 모델을 자동 선택. |
|
||||
|
||||
## 실행하면?
|
||||
입력값이 제대로 들어왔는지 확인 리포트만 출력합니다 (실제 데이터 호출 X). 키가 비어있으면 알려줍니다.
|
||||
|
||||
## 어디 저장되나?
|
||||
이 폴더의 `youtube_account.json` 한 파일에. 브레인 폴더 안이라 GitHub 백업도 같이 됩니다.
|
||||
Reference in New Issue
Block a user