the journey
따뜻하게 태어나는 계획은 없다. 능선 어딘가, 수 마일 안에 유일한 불빛 하나가 타오르는 대장간 — glm-hammer가 배송하는 모든 코드는 그 아래, 눈보라 속에서, 증거와 함께 찍혀 나온다.
LLM 에이전트의 "완료했습니다"는 검증되기 전까지 주장일 뿐입니다. glm-hammer는 판정을 독립 서브에이전트에게 맡기고, 그 판정조차 디스크에 남은 증거 파일(영수증)로 대조하며, 게이트를 통과하지 못하면 hooks가 턴 종료 자체를 차단합니다. 에이전트의 성실성을 믿는 대신, 구조가 성실성을 강제합니다.
메인 에이전트는 오케스트레이터일 뿐. 만드는 자(worker), 계약을 판정하는 자(validator), 사기를 사냥하는 자(critic), 결과를 공격하는 자(reviewer)는 전부 별도 서브에이전트이며 서로의 산출물을 보지 못합니다.
모든 판정자는 검증 리포트를 .glm-hammer/evidence/에 직접 남기고 EVIDENCE_RECORDED로 마무리합니다. 상태 파일의 주장과 영수증이 어긋나면 훅이 종료를 막습니다.
판정자는 총평 대신 고정된 yes/no 체크리스트에 답합니다. "확인 안 했으면 YES 금지." VERDICT는 느낌이 아니라 답들의 AND로 기계적으로 도출됩니다.
사용자 개입 지점은 단 두 곳 — 질문에 답할 때와 계획을 승인할 때뿐입니다. 나머지는 루프가 알아서 돕니다.
route-intent 훅이 프롬프트를 보고 알아서 라우팅하므로 스킬 이름을 외울 필요가 없습니다. 기준: 모호하거나 4개 파일 이상이면 forge, 작고 명확하면 blueprint, 계획이 이미 있으면 hammer.
작고 명확한 작업(≤3 파일)용 경량 계획. forge와 같은 포맷(binary 수용 기준, 검증 전략, 심볼 앵커)이지만 critic 패널 대신 엄격한 Self-Review로 대체. 숨은 복잡도 발견 시 스스로 forge로 승격.
질문하기 전에 Explore 서브에이전트 2~4개로 코드베이스를 정찰. 정찰이 답할 수 있는 건 절대 묻지 않음. 초안 작성 후 critic 3명이 실제 코드베이스를 대조 검증 — 전원 승인까지 수정 루프.
태스크마다 worker → validator(정보 격리) → implementation-critic(사기 탐지) 3중 검증. 전체 완료 후 E2E 게이트 → security/QA 병렬 리뷰. FAIL은 fix task가 되어 루프로 되돌아감.
구조 / 기존 패턴 / 인터페이스 경계 / 검증 인프라, 네 가지 관심사로 쪼개 Explore 서브에이전트를 병렬 파견. 사용자에게 묻기 전에 코드가 답할 수 있는 모든 것을 소진합니다.
정찰로도 남은 모호함만, 정찰 결과를 인용해서, 독립 질문 최대 4개를 한 라운드에 묶어 질문. 답이 필요 없으면 묻지 않고 통과합니다.
docs/glm-hammer/plans/에 저장. 모든 태스크는 Goal + 의존성 + 심볼 앵커 파일 목록 + 해석 여지 없는 binary 수용 기준 + 실제 코드가 담긴 스텝으로 구성. placeholder는 계획 실패로 간주.
feasibility(이대로 구현 가능한가) / integration(조립하면 돌아가는가) / coverage(요구를 다 덮는가) 세 critic이 병렬로 계획을 공격. 각자 영수증을 남기고, 하나라도 REJECT면 수정 → 전체 패널 재심사. 계획 파일을 고치는 순간 plan-gate 훅이 승인을 0으로 리셋하므로 재심사는 선택이 아니라 강제입니다. 3라운드 초과 시 사용자 에스컬레이션.
요약과 함께 계획을 제시하고 단 하나만 묻습니다: "hammer로 진행할까요?" — 승인하면 hammer가 즉시 이어받습니다.
worker가 계획대로 구현(현실과 어긋난 스텝은 최소 적응 후 보고). validator는 worker의 산출물을 전혀 보지 못한 채, 계획 원문만으로 각 수용 기준을 고립된 yes/no 질문으로 판정. 통과하면 implementation-critic이 validator가 못 보는 것 — 스텁, 테스트 맞춤 하드코딩, 삼켜진 에러, 아무것도 검증 안 하는 테스트 — 를 사냥합니다.
실패는 먼저 분류: worker 결함이면 누적된 피드백 전부를 들고 재작업, 계획 결함이면 계획 파일 자체를 수정(Amendment Log 기록, 기준 완화는 리워드 해킹으로 금지). 한 태스크 3회 실패 시 사용자 에스컬레이션.
모든 태스크 완료 후 계획의 검증 전략 명령 + 전체 테스트 스위트 실행. 원본 출력을 evidence/e2e.md에 저장 — 이 영수증이 없으면 stop-gate가 통과시키지 않습니다.
두 리뷰어가 병렬로 변경 코드를 공격 — security는 인젝션/인증/비밀키/노출을, QA는 실제 동작/엣지 케이스/회귀/테스트 적정성을 각자 binary 체크리스트로 판정. blocking finding은 fix task로 변환되어 전체 태스크 사이클을 다시 통과해야 하고, 수정 후에는 E2E와 리뷰 패널 전체를 재실행합니다.
스킬이 .glm-hammer/state.json에 상태를 기록하면, 훅이 그 상태와 디스크의 증거를 대조해 게이트를 강제합니다. ZCode 설치본 엔진 기준으로 검증된 구성입니다.
| Hook | 이벤트 | 역할 |
|---|---|---|
session-start | SessionStart | 미완료 런 발견 시 재개 브리핑 주입 — 재시작·컴팩션 후에도 "continue" 없이 자동 복귀 |
route-intent | UserPromptSubmit | 작업 요청이면 forge/blueprint/hammer 라우팅 지침 주입, 진행 중이면 현재 상태 리마인드 |
plan-gate | PostToolUse | forge 중 계획 파일 수정 감지 → critic 승인 0으로 리셋, 전체 패널 재심사 강제 |
comment-checker | PostToolUse | AI 슬롭 주석 탐지: elision 마커("... existing code ..."), 변경 나레이션, placeholder — 같은 턴에서 즉시 수정 지시 |
edit-diagnostics | PostToolUse | LSP-lite: 수정 파일 즉시 구문 검사(JS/JSON/Python) — 깨진 파일을 E2E가 아닌 수정 직후에 적발 |
stop-gate | Stop | state의 주장과 증거 영수증 대조 — 게이트 미충족 시 턴 종료 차단, 반복될수록 directive 톤 강화 |
state.json의 완료 주장은 신뢰되지 않습니다. 판정자 본인이 남긴 영수증이 디스크에 있어야만 게이트가 열립니다.
.glm-hammer/evidence/
├── critics/round-<N>/<critic>.md # VERDICT: APPROVE ×3 필요
├── tasks/task-<i>/validator.md # VERDICT: PASS
├── tasks/task-<i>/critic.md # VERDICT: APPROVE
├── e2e.md # E2E 게이트 원본 출력
└── reviews/{security,qa}.md # VERDICT: PASS탈출구도 설계되어 있습니다: 정당한 사용자 에스컬레이션(awaiting-user), 차단 6회 시 양보, 컨텍스트 압박 감지 시 차단 해제. 증거 게이트·세션 복구 패턴은 lazycodex(OmO)에서 가져왔습니다.
LLM judge는 열린 총평보다 binary 질문에서 더 신뢰할 수 있다는 관찰을 반영해, 6개 판정자 전원이 고정 체크리스트로 판정합니다.
CHECKS:
- C1: YES — 모든 함수에 실제 구현 존재
- C2: NO — parse()가 테스트 입력값에만
특화된 분기 발견 (utils.js:42)
- C3: YES — 새 테스트 모두 실패 가능
- C4: YES / C5: YES / C6: YES
VERDICT: REJECT ← NO가 하나라도 있으면 자동
FINDINGS:
- [REJECT-level] criteria-shaped
hardcoding at utils.js:parse ...각 질문에 YES / NO / N-A로만 답하고, 한 줄 근거(무엇을 확인했는지)를 붙입니다.
YES 직접 도구로 확인한 경우에만. 확인하지 않았으면 YES라고 답할 수 없다 — 확인하거나 NO.
NO 반드시 대응하는 finding(파일·심볼·증거)과 함께.
VERDICT = 모든 답의 AND. 부분 점수·"거의 됨"·조건부 통과 없음. 판정은 계산되는 것이지 느끼는 것이 아닙니다.
요구사항: Node.js 18+ (훅 스크립트 실행용, PATH에 있어야 함)
Settings → Plugin Management → 커스텀 마켓플레이스 추가 → 소스로 GitHub 저장소
tmdgusya/glm-hammer (또는 개발 중이면 로컬 클론 경로) 등록 → glm-hammer 설치.
설치 후 플러그인 상세에서 hooks 6개가 runnable로 뜨는지 확인하세요.
claude plugin marketplace add tmdgusya/glm-hammer
claude plugin install glm-hammer@glm-hammer설치 후에는 그냥 평소처럼 말하면 됩니다 — "결제 모듈 제대로 만들어줘" 한 줄이면 라우터가 forge를 태우고, 계획 승인 한 번 뒤에는 완료 보고까지 손댈 일이 없습니다.