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>
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뿐이다.