llm-wiki/vault/00-system/templates/blog-topic-template.md

title, source_type, status, related_branches, related_projects, tags, created, status_label, target_audience, inspiration_url, archive_url

title	source_type	status	related_branches	related_projects	tags	created	status_label	target_audience	inspiration_url	archive_url
blog-topic / {{short-topic-slug}}	blog-topic	raw			blog-topic project-slug	YYYY-MM-DD	captured	backend-engineer

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 후보