docs(10_Wiki): 위키 전체 재구성 — Topic_* 폴더를 4개 카테고리로 통합 + 대규모 중복 제거

Topic_Agent/Topic_Blog/Topics/Topics_Biz/Topics_Meeting/Topics_Rag의 마크다운 지식 문서를
Topic_General/Topic_Programming/Topic_Graphic/Topic_Business 4개 카테고리로 재분류.

- 중복 제거: frontmatter의 status:duplicate/merged + duplicate_of/redirect_to 필드로
  자기 자신을 중복으로 선언한 리다이렉트 stub 1032개 제거, 완전 동일 내용 파일 472개 제거,
  동일 파일명·다른 내용 충돌 시 더 큰(완전한) 버전만 유지(162개 제거) — 총 1639개 중복 제거.
- 분류: 폴더 단위로 명확한 항목(AI_and_ML/Coding/Architecture 등 → Programming,
  Comfyui/Visual_Effects → Graphic, Topics_Biz/Topics_Meeting/사업 등 → Business,
  Poetic_Blog_Writing/창의성/Game_Design 등 → General)은 폴더 우선순위로,
  나머지 혼재 폴더(Topic_Agent/Topic_Blog/Topics 루트/Thinking & Reasoning/Other/UI_UX_Assets)는
  title/tags 키워드 스코어링으로 파일 단위 분류(불명확한 경우 General로 폴백).
  원본 폴더명은 "From_*" 서브폴더로 보존해 추적 가능성 유지.
- 최종 배치: Programming 2784 / General 1608 / Graphic 285 / Business 249 = 4926개 문서.
- 에이전트 운영 상태(.astra/.agent/.obsidian/sessions/memory/_company/docs/lessons/_shared/src)는
  지식 콘텐츠가 아니므로 재분류 대상에서 제외하고 원위치 유지.
- Topics/Topic_email(상위 보호 폴더 Topic_email과 파일명 100% 중복) 삭제 — 보호 폴더 자체는 미변경.
- 완전히 비게 된 Topic_Agent/Topic_Blog/Topics_Biz/Topics_Rag 폴더 제거.

10_Wiki/Topic_Programming/Coding/Android_Compose_State_Hoisting.md

@@ -0,0 +1,111 @@
+---
+id: android-compose-state-hoisting
+title: Jetpack Compose — State Hoisting
+category: Coding
+status: draft
+source_trust_level: B
+verification_status: conceptual
+created_at: 2026-05-09
+updated_at: 2026-05-09
+tags: [android, compose, state-hoisting, vibe-coding]
+tech_stack: { language: "Kotlin / Jetpack Compose", applicable_to: ["Android"] }
+applied_in: []
+aliases: [stateful, stateless, controlled composable]
+---
+
+# Compose State Hoisting
+
+> Composable 은 가능한 stateless. state 는 호출자가 보유, **(value, onValueChange) 한 쌍** 으로 주입. 테스트 / 재사용 / preview 모두 쉬워짐. React 의 controlled component 와 같은 철학.
+
+## 📖 핵심 개념
+- Stateful: 자기 안에 `remember { mutableStateOf(...) }` 보유.
+- Stateless: state 를 외부에서 받음. 같은 입력 = 같은 UI.
+- Hoist: state 를 가장 가까운 공통 부모로 끌어올림.
+
+## 💻 코드 패턴
+
+### Stateless + 호출자 hoist
+```kotlin
+@Composable
+fun NameField(
+    name: String,
+    onNameChange: (String) -> Unit,
+    modifier: Modifier = Modifier,
+) {
+    OutlinedTextField(
+        value = name,
+        onValueChange = onNameChange,
+        label = { Text("이름") },
+        modifier = modifier,
+    )
+}
+
+// 호출자
+@Composable
+fun ProfileScreen(viewModel: ProfileViewModel) {
+    val name by viewModel.name.collectAsStateWithLifecycle()
+    NameField(name = name, onNameChange = viewModel::onNameChange)
+}
+```
+
+### 두 컴포저블이 같은 state 공유 → 부모로 hoist
+```kotlin
+@Composable
+fun PriceWidget() {
+    var price by rememberSaveable { mutableStateOf(0) }
+    Row {
+        PriceSlider(value = price, onValueChange = { price = it })
+        PriceLabel(value = price)
+    }
+}
+```
+
+### rememberSaveable — config change 에 보존
+```kotlin
+var query by rememberSaveable { mutableStateOf("") }
+// 화면 회전 시에도 유지 (Bundle 자동 복원)
+```
+
+### 복잡 state — Holder 패턴
+```kotlin
+@Stable
+class FormState(initial: String = "") {
+    var name by mutableStateOf(initial)
+    var isValid by derivedStateOf { name.length >= 2 }
+}
+
+@Composable
+fun rememberFormState(initial: String = "") = remember { FormState(initial) }
+
+@Composable
+fun Form() {
+    val state = rememberFormState()
+    NameField(name = state.name, onNameChange = { state.name = it })
+    if (state.isValid) Button(onClick = ...) { Text("제출") }
+}
+```
+
+## 🤔 의사결정 기준
+| 상황 | 패턴 |
+|---|---|
+| 한 composable 내부 UI state (toggle 펼침 등) | `remember { mutableStateOf }` |
+| 두 형제가 같은 state | 부모로 hoist |
+| screen 단위 비즈니스 state | ViewModel + StateFlow |
+| 화면 회전 보존 | `rememberSaveable` |
+| 여러 필드 + 검증 | State Holder 클래스 |
+
+## ❌ 안티패턴
+- **모든 state 를 ViewModel 까지 끌어올림**: 작은 toggle 도 viewmodel 행. 가까운 공통 부모로.
+- **stateful + props 동시 보유 (`var x by remember(...)` + `prop x`)**: 어느 게 진실?. 한쪽으로.
+- **`MutableState` 를 직접 외부 노출**: 캡슐화 깨짐. State<T> 만 노출.
+- **rememberSaveable 안에 너무 큰 객체**: Bundle 한계 / TransactionTooLarge crash.
+- **Composable 안에서 `LaunchedEffect` 없이 launch**: lifecycle 관리 안 됨.
+- **derivedStateOf 안 쓰고 매번 계산**: 불필요 recomposition.
+
+## 🤖 LLM 활용 힌트
+- "이 state 가 누구의 것인가? 가장 가까운 공통 부모는?" 매 composable 작성 시 점검.
+- ViewModel 은 비즈니스 state, composable 은 UI-local state 만.
+
+## 🔗 관련 문서
+- [[Android_Compose_Recomposition_Pitfalls]]
+- [[Android_ViewModel_State_Persistence]]