111 lines
5.0 KiB
Markdown
111 lines
5.0 KiB
Markdown
---
|
|
title: blog-topic / {{short-topic-slug}}
|
|
source_type: blog-topic
|
|
status: raw
|
|
related_branches: []
|
|
related_projects: []
|
|
tags: [blog-topic, {{project-slug}}] # L2 프로젝트 슬러그 필수 (tag-taxonomy.md §2). L3~L5 는 주제별 추가.
|
|
created: YYYY-MM-DD
|
|
status_label: captured
|
|
target_audience: backend-engineer
|
|
inspiration_url: # 외부 자료에서 영감 받았으면 원본 URL. 없으면 빈 채로.
|
|
archive_url: # inspiration_url 의 Wayback Machine 등 archive snapshot. CLAUDE.md §7.
|
|
---
|
|
|
|
# blog-topic: {{short-topic-slug}}
|
|
|
|
> Layer: `raw/blog-topics/` — 채용공고가 아닌 작업·학습·트러블슈팅에서 나온 **블로그 글감 원석**. 다듬어진 블로그 초안은 canonical (`wiki/concepts/` 또는 `wiki/projects/`) 정제 후 `/blogify` 또는 수동 작성으로 `wiki/blog/`에 별도 작성한다. 원본은 raw에 영구 보관.
|
|
> `status_label`: `captured` | `expanded` | `ready-for-canonical` | `derived-to-blog` | `parked`
|
|
|
|
> **Citation discipline (필수)**:
|
|
>
|
|
> - `## 핵심 주장 후보` 의 각 사실/경험 후보는 단순 `[[branch-note]]` 링크만으로는 부족하다. 다음 셋 중 하나를 동반한다:
|
|
> 1. branch-note 의 **Decision ID** (예: "근거: `feature-X.md` D3").
|
|
> 2. 외부 source 의 **claim ID** (예: `AT-TX-C5`, `UNIL-TX-C1`) — 가능하면 raw source 파일의 anchor 인용 (`<path>.md#AT-TX-C5`).
|
|
> 3. branch-note 의 **section + line ref** (예: `feature-X.md §결정 사항`, `feature-X.md:104`).
|
|
> - 외부 자료에 다수파 vs 소수파 trade-off 가 있다면 명시 (`다수파: @Transactional 직접 부착`, `소수파: TransactionPort 추상화` 등).
|
|
> - `## Outline seed` 의 각 섹션 후보는 `→ 핵심 메시지 한 줄` 으로 다음 글의 단락 핵심을 미리 적는다. 단순 섹션 제목만 두지 않는다.
|
|
> - `## Canonical 전환 후보` 는 추상 후보가 아니라 **구체 파일명** 까지 명시 (`wiki/projects/ca-tmpl/<topic>.md`).
|
|
> - `## 미해결 / Unknown` 의 "과장하면 안 되는 부분" 은 반드시 한 줄 이상 채운다 — local-verified / prod-verified / documented-only 의 등급을 흐리지 말 것.
|
|
|
|
## 부모
|
|
|
|
> 이 글감이 어느 작업·프로젝트에서 나왔는지 명시. **최소 1개 필수.** 일반 주제면 `[[raw/project-notes/<project>]]` 로 연결.
|
|
|
|
- `[[raw/branch-notes/{{branch-name}}]]` — <왜 이 branch에서 이 글감이 나왔는지 한 줄>
|
|
- (또는) `[[raw/project-notes/{{project-name}}]]`
|
|
|
|
## 트리거
|
|
|
|
> 어떤 사건에서 이 글감이 나왔는지 구조적으로 기록. `/lint` / `/query` 에서 trigger 유형별 필터링 가능.
|
|
|
|
- 트리거 유형: `branch-work` | `error` | `interview` | `lecture` | `conversation` | `other`
|
|
- 트리거 날짜: YYYY-MM-DD
|
|
- 트리거 연결 노트: `[[raw/branch-notes/...]]` 또는 `[[raw/errors/...]]` 또는 `[[raw/lectures/...]]` 또는 `[[raw/interviews/...]]`
|
|
|
|
## 글감
|
|
|
|
- 한 문장 요지:
|
|
- 예상 제목 후보:
|
|
- <제목 후보 1>
|
|
- <제목 후보 2>
|
|
|
|
> 타깃 독자는 frontmatter `target_audience:` 필드를 SSOT 로 사용 (중복 방지).
|
|
|
|
## 핵심 주장 후보
|
|
|
|
> 아직 canonical이 아니다. 사실/경험/의견 후보를 분리한다.
|
|
|
|
- 사실 후보:
|
|
- <검증 가능한 사실> — 근거 후보: `[[raw/branch-notes/<...>]]`
|
|
- 경험 후보:
|
|
- <내가 직접 한 작업/검증> — 근거 후보: `[[raw/branch-notes/<...>]]`
|
|
- 의견/해석 후보:
|
|
- <내 해석 또는 글의 관점>
|
|
|
|
## Outline seed
|
|
|
|
1. <섹션 후보 1> — <핵심 메시지>
|
|
2. <섹션 후보 2> — <핵심 메시지>
|
|
3. <섹션 후보 3> — <핵심 메시지>
|
|
|
|
## Canonical 전환 후보 / Canonical extraction candidates
|
|
|
|
> `wiki/blog/`로 바로 가지 않는다. 먼저 어떤 canonical 문서로 정제할지 기록한다.
|
|
|
|
- `wiki/projects/<project>/<topic>.md` 후보:
|
|
- <프로젝트 적용 사실로 승격할 항목>
|
|
- `wiki/concepts/<concept>.md` 후보:
|
|
- <일반 개념으로 승격할 항목>
|
|
- 필요한 추가 검증:
|
|
- <테스트 / 공식문서 확인 / 코드 링크 / 리뷰>
|
|
|
|
## 근거 후보
|
|
|
|
> 글감 단계의 후보 링크다. 최종 blog의 사실 근거는 canonical 문서에서 다시 검증한다.
|
|
|
|
- `[[raw/branch-notes/<...>]]` — <어떤 경험/결정의 근거인지>
|
|
- `[[raw/errors/<...>]]` — <관련 트러블슈팅이 있다면>
|
|
- `[[raw/interviews/<...>]]` — <관련 예상 질문이 있다면>
|
|
- `[[raw/official-docs/<...>]]` — <공식 근거 후보>
|
|
- `[[raw/company-tech-blogs/<...>]]` — <사례 근거 후보>
|
|
|
|
## 미해결
|
|
|
|
- 아직 확인해야 할 사실:
|
|
- 과장하면 안 되는 부분:
|
|
- 블로그로 쓰기 전에 필요한 canonical 정제:
|
|
|
|
## 처리 결정
|
|
|
|
- 액션: `keep-as-topic` | `expand` | `promote-to-canonical` | `derive-to-blog` | `park`
|
|
- 이유:
|
|
- 다음 단계:
|
|
|
|
## 관련
|
|
|
|
- 관련 branch: `[[raw/branch-notes/{{branch-name}}]]`
|
|
- 관련 error: `[[raw/errors/<...>]]` (있다면)
|
|
- 관련 interview prep: `[[raw/interviews/<...>]]` (있다면)
|
|
- derived blog: 생성 전. 생성 시 `wiki/blog/<slug>-YYYY-MM-DD.md` 후보
|