DongHyeonkaandClaude Opus 5
e00c1a2b76
R4 · R13 · R6 · R3. 네 가지가 같은 자리를 본다 — 검사기가 대상을 못 찾았을 때 무엇을
내는가.
세 상태를 가른다 (CLAUDE.md 「검사」 절의 표).
봤고 괜찮다 exit 0 문제 없음 · error 0
대상이 성립하지 않는다 exit 2 대상이 성립하지 않는다 — <이유>
볼 것이 아직 없다 exit 0 기록 0건 — 아직 쓴 기록이 없다
R4 — 없는 프로젝트를 주면 여섯 중 넷이 초록을 냈다. `verify-tech-log-tree.py` 는 그것을
「프로젝트 1 · error 0 · PASS」로 셌다 — 오타 한 번이면 검사를 다 돈 것처럼 보인다.
판정은 `techlog.check_targets()` 하나로 모은다. 여섯 곳에 같은 규칙을 따로 쓰면 다음에
하나만 어긋난다. `check_evidence.mjs` 는 이미 exit 2 라 문구만 맞춘다.
R13 — 프로젝트 이름 쪽만 고치면 `--file` 로 오타를 내는 순간 다시 조용히 0건이 된다.
`techlog.check_files()` 로 같은 자리에 둔다. `preview-figure.py` 는 인자가 아예 없을 때
exit 1 을 냈는데 그것도 「대상이 성립하지 않는다」다.
R6 — 두 자리를 함께 고쳐야 했다.
(a) `verify_projects()` 가 `docs/*/tech-log-studio` 만 훑어 계약 없는 프로젝트가
목록에서 사라졌다. 기준을 `final/document.md` 로 바꾼다 — SSOT 가 있으면 대상이다.
(b) `verify-tech-log-tree.py:194` 가 「분해 계약 없음」을 warn 으로 냈다. CLAUDE.md 는
「계약 미채택도 error 다 — 경고로 두면 옛 스키마로 남아 있는 한 검사를 피한다」고
적어 두었는데, 경고로 두었더니 실제로 그렇게 됐다.
R3 — `verify-pipeline.py` 가 `check-figure-text.py` 와 `check_evidence.mjs --repo` 를
프로젝트마다 돌린다(`OUTPUT CHECKS`). 게시 전에 돌리라고 적어 둔 검사인데 전체 훑기가
부르지 않아 결함이 있는 채로 PASS 로 보고됐다. `check-required-content.py` 자리는 주석으로
남겨 둔다 — 그 파일이 들어온 뒤에 더한다.
회귀 `scripts/tests/test_no_target.py` 7건 (92 → 99). 「실재하는 경로는 통과한다」 대조를
함께 넣는다 — 무조건 거절로 성공률을 올리는 것이 R-003 이 든 실패다. 판정을 일부러
되돌려 FAILED 가 나는 것을 확인한 뒤 복구했다.
알려진 부채는 그대로 둔다. `verify-pipeline.py` 는 exit 1 이다 — 미준수 런 1건과
`OUTPUT CHECKS` 5건, 그리고 `ca-tmpl` 의 계약 없음이 이제 `TECH LOG TREES` 에서도 보인다.
같은 사실이고 두 번 세지 않는다.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wp9jNbePAmWc5jQwCYhK9v
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뿐이다.