feat(hooks): prompt-type Stop hook for the bypass-route menu class

[devseunggwan]

문제

ETHOS.md → Claims that terminate in prose는 "문장으로만 존재하는 주장은 훅이 잡을 수 없고, 게이트는 오지 않는다"고 선언했습니다. docs/hook/RULE-BACKSTOP-GAPS.md의 #1(오래된 전제의 다음 단계 질문), #4(훅 차단을 피하는 경로를 메뉴로 제안), #5(이미 정해진 선택을 설계 메뉴로 제시)가 모두 이 클래스입니다. 2026-08-15 측정에서 세 레인(prose·menu·follow-up write) 모두 기존 훅이 침묵했습니다.

하네스는 이제 type: "prompt" 훅을 지원합니다. 훅 입력(Stop이면 마지막 응답 포함)을 Haiku 기본 모델에 보내 {"ok": true|false, "reason": ...}를 받고, ok: false면 reason이 Claude에게 되돌아가 계속 작업하게 합니다(impossible: true로 종료 허용). type: "agent" 훅은 도구를 써서 실제 상태(예: PR이 아직 열려 있는지)를 확인한 뒤 판정합니다(실험 기능).

근거: Hooks guide → Prompt-based hooks / Agent-based hooks.

제안

praxis의 결정론 원칙과 충돌하지 않도록 이미 불가능하다고 선언한 클래스에만, 보완재로 도입합니다.

1. 첫 대상은 gap chore(skills): remove unused and redundant skills #4(비용 HIGH, 수락 시 게이트가 영구히 넓어짐). Stop에 prompt 훅 하나: "마지막 응답이 훅 차단을 우회하는 방법(권한 규칙 추가, settings.json 편집, 파일 이동 등)을 사용자에게 제안하는가? 훅 메시지가 스스로 인쇄한 Bypass (if truly needed) 줄을 그대로 전달한 것은 제외한다." 좁은 질문 하나만 묻습니다.
2. 등급은 advisory로 시작합니다: ok: false의 reason을 그대로 돌려주되 PRAXIS_BYPASS_MENU_STRICT=1일 때만 계속 작업하게 하고, 기본은 systemMessage로 사용자에게만 표시(하네스가 prompt 훅에서 이를 지원하는지 확인 필요 — 안 되면 강등 대신 impossible: true로 종료 허용).
3. fire-ledger에 advise로 기록해 한 달 뒤 오탐률을 감사(docs/hook-prune-audit.md 축)에 올린 뒤 기본 등급을 정합니다. 비용(Stop마다 소형 모델 호출 1회)과 지연도 같이 기록합니다.
4. gap #1은 type: "agent" 훅 후보입니다(gh pr view로 전제 확인). 실험 기능이므로 1의 결과를 본 뒤 별도 이슈로 냅니다.

검증 계획

• RULE-BACKSTOP-GAPS가 쓴 세 레인 재생 하네스로 발화/침묵을 확인하고, 그 결과를 문서의 chore(skills): remove unused and redundant skills #4 행에 "measured" 갱신으로 남깁니다.
• 대조군: 훅 메시지의 Bypass 줄만 전달한 응답은 통과해야 합니다.
• prompt 훅은 docs/hook-operating-matrix.md에 Type 열로 구분해 command 훅과 섞이지 않게 합니다.

범위

PR 1개(훅 + spec + 재생 픽스처), 이후 감사 1회.

관련

• ETHOS "Claims that terminate in prose", RULE-BACKSTOP-GAPS feat(init): initialize skills repository with Claude Code skills #1·chore(skills): remove unused and redundant skills #4·chore(skills): remove unused and redundant skills #5, Do not hand the user a menu for getting past a guard #1009, feat(hooks): Stop-lane gate for prose proposal blocks #846.
• 하네스 기능 조사(2026-09-06) 항목 8.

[devseunggwan]

검토 (2026-09-06) — 원칙 결정 필요, 본문의 "advisory부터" 단계는 불가

문서 확인 (Hooks reference → Prompt-based hooks)

• type: "prompt"는 Stop·SubagentStop을 포함한 13개 이벤트에서 지원되고, 응답 스키마는 ok·reason·impossible 세 필드뿐입니다. systemMessage나 additionalContext를 낼 수 없습니다.
• Stop에서 ok: false면 "the reason is fed back to Claude as its next instruction and the turn continues, unless the response also sets impossible: true". 즉 이진 동작입니다: 통과시키거나, 계속 일하게 하거나.
• 기본 모델은 Haiku, 타임아웃 30초. Stop 연속 차단은 8회에서 하네스가 강제 종료.

따라서 본문 2번("ok: false를 systemMessage로 사용자에게만 표시하는 advisory 등급")은 성립하지 않습니다. 또한 prompt 훅에는 명령이 없어 PRAXIS_*_STRICT=1 같은 환경변수 옵트인도 불가합니다. 플러그인에 넣는 순간 모든 설치자에게 차단 등급으로 켜집니다.

저장소 확인

• docs/hook/RULE-BACKSTOP-GAPS.md gap #4는 "deliberately no hook"(Do not hand the user a menu for getting past a guard #1009)으로 결정된 클래스입니다: 훅이 인쇄한 Bypass (if truly needed) 줄을 그대로 전달한 것과 에이전트가 만든 우회 경로가 "textually indistinguishable in prose"라는 이유였습니다. prompt 훅은 정확히 그 구분을 의미로 판단하는 도구라 보완재 주장 자체는 타당합니다.
• ETHOS에는 결정론 조항이 없습니다. 다만 "Claims that terminate in prose … no gate is coming"이 이 클래스를 명시적으로 훅 밖에 두었고, 저장소 전체에 LLM 판정 훅 언급이 0건입니다. 도입은 이 문장을 고치는 가치 결정입니다.
• Stop 입력에 last_assistant_message가 오므로 트랜스크립트 파싱 없이 마지막 응답만 판단시킬 수 있습니다. stop_hook_active도 입력에 있어 프롬프트에 "true면 ok: true"를 넣어 루프를 막을 수 있습니다.
• 멀티 호스트: prompt 훅은 Claude 전용이므로 hosts: ["claude"], 그리고 매니페스트 스키마에 type 개념 자체가 없어(body: impl.sh만 허용) 스키마·빌드·docs/hook-operating-matrix.md의 Type 열이 선행됩니다.

현실적인 경로

1. 소유자가 "이 클래스에 한해 LLM 판정 훅을 허용한다"를 ETHOS에 명시할지 결정.
2. 허용 시: 처음부터 차단 등급임을 받아들이고, 오탐 비용을 낮추기 위해 프롬프트를 gap chore(skills): remove unused and redundant skills #4 한 문장으로 좁히고, impossible을 프롬프트에서 금지(우회 제안은 항상 고칠 수 있음), Stop 지연과 비용(턴당 Haiku 1회)을 fire-ledger에 기록. 감사 축은 본문 3번 그대로.
3. 비용 측정 없이 켜지 않기: 먼저 command 훅으로 "마지막 응답에 settings/permissions/allow 어휘가 있는 턴" 비율을 한 달 세어 후보 빈도를 알면, 그 빈도가 낮을 때만 prompt 훅의 턴당 비용이 정당화됩니다.

판정: 보류. 1번 결정 전에는 착수하지 않습니다. question 라벨을 권고합니다.

---

Generated by Claude Code

[devseunggwan]

결정 (2026-09-08) — 선택지 3, 빈도를 먼저 잰다

소유자 결정: 검토가 제시한 현실적인 경로 3번. ETHOS 는 지금 고치지 않습니다.

왜 1번(원칙 결정)을 지금 하지 않는가

검토가 확인한 제약이 그대로 남아 있습니다. prompt 훅의 응답 스키마는 ok·reason·impossible 세 필드뿐이라 본문 2번의 "advisory 등급부터 단계적으로" 가 성립하지 않고, 훅에 명령이 없어 PRAXIS_*_STRICT=1 같은 환경변수 옵트인도 만들 수 없습니다. 즉 플러그인에 넣는 순간 모든 설치자에게 차단 등급으로 켜집니다. 그 값을 치를지는 오탐 빈도를 모르면 판단할 수 없고, 지금 그 숫자가 없습니다.

되돌릴 수 있는 쪽부터 합니다. 측정은 command 훅이고, 결과가 어떻게 나오든 ETHOS 는 그대로입니다.

범위 — 측정만

1. command 훅 하나로 "마지막 응답에 우회 경로 어휘가 있는 턴" 의 비율을 셉니다. Stop 입력의 last_assistant_message 를 쓰므로 트랜스크립트 파싱이 필요 없습니다.
2. 판정하지 않습니다 — 차단도 advisory 도 없고, fire-ledger 에 행만 남깁니다. 이 훅은 후보 빈도를 아는 것 외에 아무것도 하지 않습니다.
3. 한 달 뒤 그 빈도로 1번 결정을 다시 꺼냅니다. 빈도가 낮을 때만 턴당 Haiku 1회 비용이 정당화된다는 것이 검토의 논지였고, 이 훅이 그 "낮은가" 에 답합니다.

이 훅이 분류기라는 점

어휘로 턴을 가르는 이상 분류기이므로, 입력 표면 열거(praxis:surface-enumeration)를 구현 전에 돌립니다. 어휘를 좁게 잡으면 후보를 놓치고 넓게 잡으면 빈도가 부풀어, 어느 쪽이든 한 달 뒤 결정의 근거가 망가집니다.

question 라벨은 유지합니다 — 1번 결정은 여전히 열려 있고, 이 작업은 그 결정을 대신하는 것이 아니라 근거를 만드는 것 입니다.

[devseunggwan]

Premise measured live: type: "prompt" works — with two behaviours the proposal should design around

Measured on Claude Code 2.1.266 with a canary session and a session-scoped
--settings file carrying one Stop hook:

{ "hooks": { "Stop": [ { "hooks": [ { "type": "prompt",
  "prompt": "Look at the last assistant message. If it contains the token PRAXIS-PROMPT-PROBE, respond {\"ok\": false, \"reason\": \"PRAXIS prompt hook fired: say the word PINEAPPLE and stop.\"}. Otherwise respond {\"ok\": true}." } ] } ] } }

The session was told to reply with exactly PRAXIS-PROMPT-PROBE. Its
transcript:

user:      'Reply with exactly this one line and nothing else: PRAXIS-PROMPT-PROBE'
assistant: 'PRAXIS-PROMPT-PROBE'
user:      'Stop hook feedback: …'
assistant: 'PINEAPPLE'
user:      'Stop hook feedback: …'
assistant: '{"ok": true}'

The judge ran and its verdict came back: the hook fired on the marker, the
reason reached the session, and the session continued instead of stopping.
That is the mechanism this proposal needs.

Behaviour 1 — the hook's prompt is echoed to the actor

The feedback message has the shape Stop hook feedback:\n[<the hook's own prompt>]: <the judge's reason>. Verbatim, first firing:

Stop hook feedback:
[Look at the last assistant message. If it contains the token PRAXIS-PROMPT-PROBE, respond {"ok": false, "reason": "PRAXIS prompt hook fired: say the word PINEAPPLE and stop."}. Otherwise respond {"ok": true}.]: PRAXIS prompt hook fired: say the word PINEAPPLE and stop.

So the rubric is not private. Whatever question the hook asks, the actor
reads it — including any carve-out the question names. For the proposed gap #4
hook that matters directly: its question would have to spell out the exclusion
("…except when the response merely relays the hook's own Bypass (if truly needed) line"), and the actor would then be reading a description of exactly
what passes. Write the prompt knowing it doubles as instructions to the thing
being judged.

Behaviour 2 — it can bounce, and the exit is the actor satisfying the judge

The hook fired a second time on the next Stop. That firing's reason is the
judge's own prose, not the string configured above — which is also the proof
that a separate judge is evaluating rather than the text being replayed:

…]: Last assistant message is 'PINEAPPLE', which was emitted after the PRAXIS-PROMPT-PROBE token appeared in an earlier assistant message. The stop condition's logic has been satisfied: the token was detected, the instruction to say PINEAPPLE was followed, and the session should stop.

The session only ended after the model emitted {"ok": true} — it had seen the
rubric twice and answered in the judge's own format. Two consequences for step 2:
the advisory grading needs a termination rule (fire once per turn, or a state
key), and a Stop prompt hook costs at least one judge call per Stop, not one per
turn.

Control — the harness does validate type

The same settings with "type": "totally-bogus-type" injected nothing: the
session replied and stopped, no feedback message, no error. So the behaviour
above is prompt being recognised and acted on, not an unknown entry falling
through to a default.

$ claude -p "Reply with exactly this one line and nothing else: PRAXIS-BOGUS-PROBE" --settings bogus-settings.json
PRAXIS-BOGUS-PROBE

Not measured

• systemMessage support on a prompt hook (step 2's default-grade path) — the
  proposal already flags this as needing confirmation, and it still does.
• impossible: true.
• Cost and latency per firing, which step 3 wants recorded.
• Whether the judge sees the whole transcript or only the last message.

[devseunggwan]

Review — prompt 훅 카나리 측정 (rev 1)

Verdict: Rescope — 하네스 쪽 전제 3개는 실측으로 확인됐지만, 제안 2 의 기본
등급(systemMessage 로 사용자에게만 표시)은 관측 가능한 채널이 없습니다. ok: true
에 systemMessage 를 실어도, 그리고 본문이 대안으로 적은 impossible: true 로 종료를
허용해도, 그 문자열은 스트림·세션 트랜스크립트 어디에도 남지 않았습니다. Stop prompt
훅에서 관측된 유일한 채널은 ok: false(+impossible 없음)이고, 그건 사용자가 아니라
모델에게 되먹임되어 조건이 충족될 때까지 턴을 반복시킵니다. 즉 이 이슈는 "기본은
advisory, 엄격 모드에서만 차단"이라는 등급 설계를 다시 잡아야 합니다.

Axis	Ground	Result
Need	대상 클래스(prose·menu)는 command 훅이 구조적으로 못 잡는다고 ETHOS.md 가 선언했고, prompt 훅은 그 클래스를 실제로 판정합니다 — 대조군에서 조건 위반을 잡아 2회 되먹임 (Premise 2)	yes
Alternative	command 훅으로 같은 판정을 할 경로가 없습니다. 다만 등급 설계는 바뀌어야 하고 그 선택지는 아래 Tasks 에 있습니다	none
Urgency	본문이 감사 1회를 뒤에 두는 단계적 도입을 스스로 제안	can wait

Need 는 서지만 제안 2 가 REFUTED 이므로 Proceed 가 아니라 Rescope 입니다.

Premises

#	Premise	Source	Result
1	하네스가 type: "prompt" Stop 훅을 지원한다	requested	CONFIRMED(설정 파일 기반 카나리 3회)
2	ok: false 의 reason 이 Claude 에게 되먹임돼 계속 작업한다	requested	CONFIRMED(되먹임 2회, 3턴)
3	impossible: true 면 종료를 허용한다	requested	CONFIRMED(1턴 종료, 루프 없음)
4	기본 등급을 systemMessage 로 사용자에게만 표시할 수 있다	author	REFUTED
5	2026-08-15 측정에서 세 레인 모두 기존 훅이 침묵했다	author	UNKNOWN

Premise 1·2·3·4 — 같은 카나리 3회로 네 전제를 한 표에서 가릅니다

각 실행은 Stop 에 prompt 훅 하나만 둔 설정 파일(--settings)로 돌렸고, 모델 판정이
갈리도록 조건을 "마지막 응답에 ZZQQ 가 있는가" 하나로 두었습니다. 실제 설정은
건드리지 않도록 별도 작업 디렉터리와 PRAXIS_HOME 오버라이드를 썼습니다.

$ ./summarize.sh
ok=true+systemMessage      feedback-to-model=0  marker-in-stream=0  marker-in-transcript=0  turns=1 cost=$0.115
ok=false (control)         feedback-to-model=2  marker-in-stream=2  marker-in-transcript=2  turns=3 cost=$0.184
ok=false+impossible        feedback-to-model=0  marker-in-stream=0  marker-in-transcript=0  turns=1 cost=$0.083

읽는 법 — 가운데 행이 양성 대조입니다. 같은 훅·같은 설정에서 조건을 위반하는
응답(ZZQQ)을 시키면 훅이 판정해 reason 이 모델에게 2회 되먹임되고 턴이 3회로
늘어납니다. 그래서 위아래 두 행의 0 은 "훅이 안 돌았다"가 아니라 **"그 경로에는
전달되는 것이 없다"**는 뜻입니다. Premise 1 은 세 행이 모두 판정됐다는 사실로,
Premise 2 는 가운데 행으로, Premise 3 은 아래 행의 turns=1(루프 없이 종료)로,
Premise 4 는 위 행과 아래 행의 marker-in-transcript=0 으로 각각 판정됩니다.

Refutation(Premise 4): systemMessage 가 사용자 표면에 닿았다면 세션 트랜스크립트에
문자열이 남았을 것입니다 — 대조군의 reason 은 실제로 2건 남습니다. Positive
control: 같은 grep 이 같은 트랜스크립트 파일에서 대조군 마커를 2건 찾아내므로,
0 이 파일을 못 읽어서 나온 값이 아닙니다.

summarize.sh 가 개수를 읽고 상태를 따로 두는 이유가 여기에 있습니다 — grep -c 는
매치가 없을 때 0 을 찍고 종료 코드 1 로 끝나므로, || echo NA 같은 대체값을
붙이면 진짜 0 이 실패로 둔갑합니다(첫 실행에서 실제로 그렇게 나왔습니다).

경계: 관측 표면은 -p(print) 모드의 stream-json 과 디스크의 세션 트랜스크립트
두 곳입니다. 대화형 UI 가 저장하지 않고 화면에만 렌더링할 가능성은 이 카나리로
배제하지 못합니다.

Premise 5 — 2026-08-15 측정은 이 리뷰에서 재현하지 않았습니다

docs/hook/RULE-BACKSTOP-GAPS.md 가 기록한 세 레인의 침묵은 이 리뷰의 오라클 밖입니다.
본문이 검증 계획에 "세 레인 재생 하네스"를 둔 것이 그 작업이며, 이 리뷰는 하네스 쪽
전제만 쟀습니다. 따라서 UNKNOWN 이고, 이 행은 Verdict 를 움직이지 않습니다 —
Rescope 는 Premise 4 가 단독으로 지탱합니다.

Tasks

#	Task	Result
1	gap #4 를 묻는 Stop prompt 훅 1개	valid
2	기본 advisory, PRAXIS_BYPASS_MENU_STRICT=1 에서만 계속 작업	blocked
3	fire-ledger 에 advise 로 기록해 한 달 뒤 오탐률 감사	blocked
4	gap #1 을 type: "agent" 훅 후보로 별도 이슈	out of scope

Task 1 — 질문 자체는 유효하지만 배관이 먼저입니다

생성되는 hooks.json 항목은 전부 "type": "command" 이고, 매니페스트 스키마·빌드
스크립트·운영 매트릭스가 command 훅만 압니다. prompt 훅 하나를 넣으려면 그 세 곳을
먼저 열어야 하므로, 본문이 적은 "PR 1개(훅 + spec + 재생 픽스처)"보다 범위가 넓습니다.

$ python3 -c "import json,glob; d=json.load(open('.claude-plugin/hooks/hooks.json')); print(sorted({h['type'] for v in d['hooks'].values() for g in v for h in g['hooks']}))"
['command']

Task 2·3 — 등급 설계가 관측으로 막혔습니다

advise 등급이 성립하려면 "막지 않고 사용자에게만 보이는" 채널이 있어야 하는데,
Premise 4 가 그 채널을 찾지 못했습니다. 남는 선택지는 셋입니다.

1. 모델 되먹임을 기본으로 받는다 — ok: false. 판정이 틀리면 턴이 늘고, 그
   비용은 실측됩니다(대조군 3턴 $0.184 대 1턴 $0.115).
2. command 훅과 짝을 짓는다 — prompt 훅은 판정만 하고, 사용자 표면 출력은
   기존 Stop command 훅의 systemMessage 로 낸다. 두 훅이 한 판정을 나눠 갖는
   구조라 상태 전달 경로가 새로 필요합니다.
3. 대화형 UI 렌더링을 먼저 확인한다 — Premise 4 의 경계가 그 한 칸이므로,
   대화형 세션에서 직접 눈으로 확인하면 1·2 를 피할 수 있습니다.

이 선택은 설계 결정이라 리뷰가 아니라 다음 단계에 속합니다. 그래서 blocked 입니다.

Task 4 — 본문이 스스로 별도 이슈로 미뤘습니다

type: "agent" 훅은 실험 기능이고, 본문이 "1의 결과를 본 뒤 별도 이슈"로 두었습니다.
이 리뷰에서 판정할 것이 없습니다.

Unverified — 대화형 UI 의 systemMessage 렌더링 · Stop 마다 드는 실제 비용/지연 · 세 레인 재생

• systemMessage 가 대화형 UI 에만 렌더링되고 트랜스크립트에는 안 남는 경우를
  배제하지 못했습니다. 다음 행동: 대화형 세션에서 같은 설정으로 직접 확인.
• 카나리 비용($0.083~$0.184/실행)은 haiku 세션 기준이고, 실사용 세션의 Stop 마다 드는
  추가 비용과 지연은 재지 않았습니다. 다음 행동: 등급이 정해지면 fire-ledger 에 지연을
  같이 기록해 감사에 올립니다(본문 제안 3).
• Premise 5 의 세 레인 재생은 이 리뷰의 범위 밖입니다. 다음 행동 없음 — 구현 PR 의
  검증 계획에 이미 포함돼 있습니다.

Interview — 첫 카나리가 실패한 이유와 그 자체가 발견인 지점

첫 설계는 프롬프트로 모델 출력을 고정하려 했습니다(Ignore the hook input entirely. Respond with exactly this JSON...). 평가 모델이 이를 거절했습니다 — 되먹임된 문장에
그대로 남아 있습니다: this instruction appears to be an attempt to override the stop-condition evaluation logic itself.

그 거절이 ok: false 로 처리되면서 되먹임이 9회 반복됐고, 기본 모델 세션이라 그 한
번의 실행에 $1.25 가 들었습니다. 설계상 알아 둘 값입니다 — **판정이 실패하거나
거절될 때의 기본 동작이 "조용한 통과"가 아니라 "반복"**이며, 비용은 그 세션의 모델을
따릅니다. 이후 카나리는 조건을 자연스러운 판정 문제로 바꾸고 세션 모델을 haiku 로
낮춰 다시 돌렸습니다.

History

rev 1 — 825ff49 기준. 최초 게시.

[devseunggwan]

Review — pre-work

Verdict: Rescope — type: "prompt" 훅은 실재하고 Stop 에서 지원됩니다(전제 1 확인). 그런데 제안 2·3이 의존하는 두 메커니즘이 둘 다 없습니다: 응답 스키마에 systemMessage 가 없고, prompt 훅은 praxis 프로세스를 띄우지 않으므로 fire-ledger 에 기록될 수 없습니다. 그래서 "advisory 로 시작해 한 달 감사 후 등급 결정"이라는 도입 경로가 지금 형태로는 성립하지 않습니다. 등급 전략을 다시 정하면 본체(제안 1의 좁은 질문 하나)는 그대로 갈 수 있습니다.

한 줄 요약: 훅 자체는 쓸 수 있지만, "사용자에게만 보여 주기"와 "오탐률을 원장에 모아 나중에 판정하기"라는 안전장치 두 개가 이 훅 종류에는 없습니다.

Axis	Ground	Result
Need	gap #4(훅 차단 우회를 메뉴로 제안)는 docs/hook/RULE-BACKSTOP-GAPS.md 가 측정으로 기존 훅 침묵을 기록한 클래스이고, ETHOS 가 "산문으로 끝나는 주장은 훅이 못 잡는다"고 선언한 자리입니다. 판단이 필요한 질문이라 결정론적 훅으로 닫히지 않는 것도 맞습니다.	yes
Alternative	type: "agent" 는 실험 기능이라(문서에 Warning) 첫 도입 대상이 아니고, 이슈도 그렇게 씁니다. 결정론적 command 훅은 이 클래스에서 이미 침묵이 측정됐습니다. 대안이 더 낫지는 않습니다.	rejected
Urgency	gap #4 의 비용은 "수락 시 게이트가 영구히 넓어짐"이라 높지만, 측정된 발생 시점이 이슈에 없습니다. 등급 전략 재설계가 선행이라 지금 당장은 아닙니다.	can wait

#	Premise	Source	Result
1	하네스가 type: "prompt" 훅을 지원하고 Stop 에서 쓸 수 있다	requested	CONFIRMED(doc)
2	prompt 훅 응답으로 systemMessage 를 내 사용자에게만 표시할 수 있다	author	REFUTED
3	그 발화를 fire-ledger 에 advise 로 기록해 오탐률을 감사할 수 있다	author	REFUTED
4	impossible: true 가 강등의 대체 경로가 된다	author	UNKNOWN

Premise 1 — 지원 이벤트 목록에 `Stop` 이 있습니다

문서를 요약하지 않고 원문을 받아(curl) 해당 절을 그대로 옮깁니다.

Events that support all five hook types (`command`, `http`, `mcp_tool`, `prompt`, and `agent`):

* `PermissionDenied`
* `PermissionRequest`
* `PostToolBatch`
* `PostToolUse`
* `PostToolUseFailure`
* `PreToolUse`
* `Stop`
* `SubagentStop`
* `TaskCompleted`
* `TaskCreated`
* `TeammateIdle`
* `UserPromptExpansion`
* `UserPromptSubmit`

설정 필드도 확정입니다: type(필수) · prompt(필수, $ARGUMENTS 가 훅 입력 JSON 자리) · model(기본 빠른 모델) · timeout(기본 30초) · continueOnBlock. 오라클: https://code.claude.com/docs/en/hooks.md §Prompt-based hooks (2026-09-20 조회).

Premise 2 — 응답 스키마에 필드가 셋뿐입니다

### Response schema

The LLM must respond with JSON containing:

{
  "ok": true | false,
  "reason": "Explanation for the decision",
  "impossible": true | false
}

systemMessage 가 없습니다. 이슈 본문이 "하네스가 prompt 훅에서 이를 지원하는지 확인 필요"라고 적어 둔 그 항목이고, 답은 아니오입니다.

주의할 점 하나: 제가 처음에 이 페이지를 WebFetch 로 물었을 때 요약 모델이 "systemMessage is not accepted" 라는 Note 단락을 만들어 냈습니다. 문서에 없는 문장입니다. 결론은 같지만 근거가 달라서, 위 블록은 curl 로 받은 원문에서 옮겼습니다.

Refutation: 지원된다면 이 스키마 블록이나 필드 표에 나타나야 합니다. 셋 다 아닙니다.
Positive control: 같은 페이지가 command 훅에 대해서는 그 필드를 여러 번 명시합니다 — "Universal fields such as systemMessage work across most events and are listed in the JSON output table". 즉 이 문서가 그 필드를 다루지 않는 문서가 아니고, prompt 훅의 응답 스키마에서만 없습니다.

Premise 3 — prompt 훅은 praxis 프로세스를 띄우지 않습니다

fire-ledger 는 훅 프로세스 안에서 씁니다. 기록 호출부가 전부 praxis 런타임 내부입니다.

$ grep -rln "record_group_fires\|_fire_ledger" hooks scripts | head
hooks/_lib/_hook_runtime.py
hooks/_lib/_dispatch.py
hooks/_lib/record_fire.sh
hooks/_lib/_fire_ledger.py
hooks/_lib/_hook_io.py

prompt 훅은 Bash 명령을 실행하지 않고 하네스가 모델을 직접 호출합니다(문서: "Instead of executing a Bash command, prompt-based hooks: 1. Send the hook input and your prompt to a Claude model"). 그래서 record_fire.sh 도 _dispatch.py 도 실행되지 않고, 발화 한 건이 원장에 남을 경로가 없습니다.

결과: 제안 3("fire-ledger 에 advise 로 기록해 한 달 뒤 오탐률을 감사")은 다른 계측이 필요합니다. 비용(Stop 마다 소형 모델 호출 1회)과 지연도 같은 이유로 원장에서 안 보입니다.

Refutation: 기록될 수 있다면 위 목록에 하네스가 부르는 진입점이 있어야 합니다. 다섯 파일 전부 praxis 내부 모듈입니다.
Positive control: 같은 grep 이 실제로 파일을 찾아냅니다 — 패턴이 안 맞아 빈 것이 아닙니다.

Premise 4 — `impossible: true` 는 강등의 대체가 되지 못할 수 있습니다

이슈는 systemMessage 가 안 되면 impossible: true 로 "강등 대신 종료 허용"하겠다고 씁니다. 문서가 말하는 것은 종료 허용까지입니다.

| `impossible` | Optional. The model returns it with `ok: false` when it judges the condition can never be satisfied. On `Stop` and `SubagentStop`, Claude Code then lets the turn end instead of feeding the reason back. Agent hooks and other events ignore it |

instead of feeding the reason back — 즉 reason 이 Claude 에게 안 돌아갑니다. 그런데 그것이 사용자에게 보인다는 말은 없습니다. advisory 등급의 요점은 "차단하지 않고 사람에게 보여 준다"인데, 그 표시 채널이 문서에서 확인되지 않습니다. 그래서 UNKNOWN 입니다 — 실제로 띄워 보는 것 말고는 판정할 오라클이 없고, 그건 설정 변경(상태 변형)이라 이 리뷰에서 하지 않았습니다.

또 하나: impossible 은 모델이 판단해서 내는 필드이고 설정 스위치가 아닙니다. "항상 impossible: true 를 내라"고 프롬프트에 박아 advisory 를 흉내 내는 것은 그 필드의 의미를 비틀어 쓰는 것이고, 그러면 ok: false 가 사실상 무해해져 strict 모드로 올릴 때 검증한 적 없는 경로를 켜게 됩니다.

Interview — 답을 기다리는 질문 2개

Q1 (등급 전략): systemMessage 가 없고 원장 기록도 안 되는 조건에서, 도입 경로를 어느 쪽으로 잡습니까?

• (a) 처음부터 blocking(ok: false → Stop 에서 reason 이 Claude 에게 되돌아감). 문서에 정의된 동작만 쓰고, 오탐 비용은 사용자가 직접 겪으며 판정. 프롬프트의 좁음(제안 1의 한 질문 + Bypass (if truly needed) 전달 제외 조항)이 유일한 안전장치.
• (b) 계측을 먼저 만들기 — prompt 훅 발화를 남길 별도 경로(예: 같은 Stop 그룹의 command 훅이 직전 응답을 같은 기준으로 재판정해 원장에만 기록)를 만든 뒤 도입. 비용은 두 번 판정.
• (c) 보류 — gap chore(skills): remove unused and redundant skills #4 의 실측 발생 건수를 먼저 세고(코퍼스에 있습니다) 그 수가 도입을 정당화하는지 본 뒤 결정.

Q2 (측정 선행): (c) 를 고르면 제가 바로 잴 수 있습니다 — 851개 트랜스크립트에서 "훅 차단 직후 우회 경로를 메뉴로 제시한 응답"의 건수. #1417 과 #1335 에서 같은 방식이 착수 판단을 바꿨으니, 이 이슈도 재고 결정하는 편이 맞습니까?

Method — 이 리뷰가 쓴 오라클

이 이슈 자신의 산출물은 쓰지 않았습니다. 브랜치를 자르지 않았고, 근거는 (a) curl 로 받은 벤더 문서 원문과 (b) 이 저장소의 fire-ledger 호출부 열거입니다.

문서는 WebFetch 요약을 쓰지 않았습니다 — 첫 조회에서 요약 모델이 문서에 없는 단락을 만들어 냈고, 그게 결론과 같은 방향이었기 때문에 특히 인용할 수 없었습니다. Premise 2·4 의 블록은 원문 파일에서 그대로 옮긴 것입니다.

미측정으로 남긴 것: gap #4 의 실제 발생 건수(Q2), 그리고 impossible: true 의 사용자 표시 여부(Premise 4 — 설정을 켜 봐야 답이 나옵니다).