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>

10_Wiki/Topics/Domain_Programming/Coding/Testing_Snapshot_Patterns.md

@@ -0,0 +1,105 @@
+---
+id: testing-snapshot-patterns
+title: Snapshot Test — 적절한 사용처
+category: Coding
+status: draft
+source_trust_level: B
+verification_status: conceptual
+created_at: 2026-05-09
+updated_at: 2026-05-09
+tags: [testing, snapshot, jest, vibe-coding]
+tech_stack: { language: "Jest / Vitest", applicable_to: ["Web", "Backend"] }
+applied_in: []
+aliases: [toMatchSnapshot, inline snapshot, golden file]
+---
+
+# Snapshot Test
+
+> 의도적으로 사용하면 강력하지만 무지성으로 쓰면 "test 가 그냥 현재 출력을 freeze" 함. 변경 → snapshot 갱신 → 의미 없는 통과. **diff 검토 문화** 가 핵심.
+
+## 📖 핵심 개념
+- 첫 실행: 출력 기록.
+- 이후: 기록과 다르면 fail.
+- Inline snapshot: test 파일에 직접 (변화 즉시 보임).
+- File snapshot: 별도 `.snap` 파일.
+
+## 💻 코드 패턴
+
+### React 컴포넌트 — 보수적 사용
+```ts
+import { render } from '@testing-library/react';
+
+test('Header renders title', () => {
+  const { container } = render(<Header title="Hello" />);
+  expect(container).toMatchSnapshot();
+});
+```
+
+⚠️ 큰 컴포넌트는 변화 잦음. inline + 핵심만 권장.
+
+### Inline snapshot — diff 즉시 visible
+```ts
+import { test, expect } from 'vitest';
+
+test('format duration', () => {
+  expect(formatDuration(95_000)).toMatchInlineSnapshot(`"1m 35s"`);
+  // jest --ci 면 fail / 로컬 --updateSnapshot 으로 갱신
+});
+```
+
+### Serializer — 핵심만 비교
+```ts
+expect.addSnapshotSerializer({
+  test: (val) => val instanceof Date,
+  print: () => '"<Date>"',
+});
+
+// timestamp 같이 매번 다른 값은 mask
+test('user object', () => {
+  expect(makeUser()).toMatchSnapshot();
+  // {"id": "<Date>", "createdAt": "<Date>", ...}
+});
+```
+
+### Property snapshot — 동적 값 마스킹
+```ts
+expect(user).toMatchSnapshot({
+  id: expect.any(String),
+  createdAt: expect.any(Date),
+});
+```
+
+### Golden file — 큰 출력
+```ts
+test('SQL builder generates expected query', async () => {
+  const sql = build({ table: 'users', filters: { age: 18 } });
+  await expect(sql).toMatchFileSnapshot('./golden/users.sql');
+});
+```
+
+## 🤔 의사결정 기준
+| 사용처 | snapshot 적합 |
+|---|---|
+| 작은 안정적 컴포넌트 | ✅ 단 inline + 짧게 |
+| 큰 페이지 컴포넌트 | ❌ — assertion 으로 행위 검증 |
+| 빌더 / 직렬화 결과 | ✅ — golden file |
+| API 응답 형식 | ❌ — schema 검증 (zod) 권장 |
+| CSS-in-JS 출력 | ❌ — 자주 바뀜 |
+| 에러 메시지 텍스트 | ✅ inline |
+
+## ❌ 안티패턴
+- **`-u` 무지성**: CI 빨갛다고 자동 update. 의미 없는 통과.
+- **거대 snapshot**: diff 못 읽음. 작은 단위로 분할.
+- **timestamp / random / uuid 안 마스킹**: 매번 fail. property matcher.
+- **snapshot only test**: 비즈니스 행위 검증 0. assertion 결합.
+- **inline 안 쓰고 매번 .snap 파일 열기**: 흐름 깨짐. 작은 출력은 inline.
+- **eslint-plugin-jest 의 `no-large-snapshots` 무시**: 50줄 넘는 snapshot 은 검토 신호.
+- **PR 에서 snapshot 변경 review 안 함**: 사일런트 회귀.
+
+## 🤖 LLM 활용 힌트
+- "snapshot 보단 명시적 assertion 우선. snapshot 은 builder/format/error 메시지 같은 안정 출력만" 명시.
+- 동적 값은 property matcher 로 마스킹.
+
+## 🔗 관련 문서
+- [[Testing_Test_Pyramid]]
+- [[Testing_Faker_and_Builders]]