Files
document-haness/.agents/skills/writing-tech-log-records
DongHyeonkaandClaude Opus 5 b2963105a8 docs(keycloak-session-store): import the session-storage lab as a new project
The keycloak project ended with four open questions that design could not
settle. A two-VM lab was built to answer them by measurement, and this is
that material: 26 experiments, 125 raw command outputs, 22 browser captures.

Follows the import procedure in README.md.

  source/     the originating repository verbatim — 78 documents, 28 SVGs,
              8 manifests, plus .source-revision recording the commit
  final/      the SSOT
    document.md   729 lines written from the 29 experiment documents, not
                  concatenated: what was predicted, what was measured, and
                  where the measurement itself was wrong
    evidence/raw    125 outputs, flattened to <experiment>__<file> because
                    the originals collided (01-baseline.txt appeared three
                    times) and the audit only globs the top level
    evidence/meta   one per raw file; command and exitCode are null and the
                    README says why rather than inventing them
    evidence/browser  22 captures
    assets/       three diagrams through techviz
    .techviz/     their VizSpecs

A separate project rather than an addition to keycloak: the B-layer answers
that project's four questions, but the A, C and D layers are about cluster
failure, SSO and operations, and one document.md should hold one subject.
The four question records there can point here through 관계.

Recorded rather than papered over: only three of the 28 diagrams were
remade. The repository forbids hand-drawn SVG and forbids titles inside the
canvas; all 28 originals carry both, so converting them is redrawing, not
reformatting. They stay in source/ and the gap is written into the document.

verify-pipeline.py passes. audit-records.py reports no issues.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-04 22:51:59 +09:00
..

writing-tech-log-records

Tech Log Studio에 올릴 기록을 쓰는 스킬. Case · Concept · Reference · Question · Decision 다섯 종류의 종류 선택, 칸 채우기, Case 본문 작성, 게시 전 대조를 다룬다.

파일

파일 무엇
SKILL.md 진입점. 종류 선택과 절차
references/record-kinds.md 다섯 종류의 칸·상한·게시 조건
references/from-ssot-to-records.md 긴 글에서 글감을 뽑는 기준과 tech-log-tree.json
references/writing-each-kind.md 종류마다 무엇을 어떤 순서로 쓰나
templates/*.md 종류별 빈 틀. 복사해서 채운다
references/body-syntax.md Case 본문의 허용·금지 문법
references/code-tables-diagrams.md 코드블록·표·SVG·이미지
references/explaining.md 설명의 깊이와 말투
references/review-checklist.md 게시 전 대조
examples/case-body.md 통과하는 본문 예시
scripts/check_body.mjs 본문을 Studio 파서로 미리 검사

본문 미리 검사

Studio에 붙여넣기 전에 확인한다. Studio가 쓰는 파서를 그대로 부르므로, 통과하면 저장도 통과한다.

node --experimental-transform-types \
  .agents/skills/writing-tech-log-records/scripts/check_body.mjs 초안.md

tech-log-frontend 체크아웃이 기본 경로에 없으면 알려 준다.

node --experimental-transform-types scripts/check_body.mjs 초안.md \
  --frontend /path/to/tech-log-frontend
# 또는 TECH_LOG_FRONTEND 환경변수

통과하면 블록 구성을, 실패하면 줄·칸과 이유를 낸다.

PASS  14개 블록 — CALLOUT 2 · CODE_BLOCK 1 · DATA_TABLE 1 · …
FAIL  초안.md:3:1  unsupported block syntax: html

계약 기준

계약 버전
@tech-log/studio-contract 3.1.0
@tech-log/public-contract 2.1.0

계약이 올라가면 body-syntax.md의 허용 목록과 record-kinds.md의 상한을 다시 맞춘다. 특히 블록 유니온(CaseRenderBlock)에 타입이 늘면 쓸 수 있는 문법이 늘어난다.

알아둘 제약

코드·표·다이어그램·이미지는 본문에만 들어간다. 본문이 있는 종류는 Case 와 Concept 이다. Reference·Question·Decision의 모든 칸은 평문으로 렌더링된다. 설계상 그렇다 — 본문을 가진 종류는 Case뿐이다.