Gate E Procedure (follow order strictly)

0. Autonomous lane only — review card (sessions approved with 「자율 레인 승인」; skip otherwise). This is the lane's one human stop after approval.
   • Run python3 "${CLAUDE_PLUGIN_ROOT}/hooks/lane_card.py" card --run and paste its output verbatim. The script re-runs the plan's acceptance commands and counts the diff itself — do not restate or soften its flags.
   • If the script exits non-zero (no archive_path to hold the ledger), stop and tell the user; do not continue without a card.
   • STOP and wait. The user answers 「카드 승인」 or 「지적: 심각|경미 — 내용」.
   • Record the answer before anything else: lane_card.py verdict --verdict 승인 (or 경미/심각 with --note "내용"). Then continue with step 1. A 심각 finding goes into the WORKLOG line and the archive as well.

1. WORKLOG record — add to the top of <worklog_path>/YYYY-Www.md (worklog_path from .claude/harness-answers.yml) in the format below:

   ## YYYY-MM-DD | Claude | 작업 한줄 요약
   **요청 내용**: ...
   **변경 파일**: - `경로/파일.tsx` — 이유
   **핵심 변경**: 무엇을 왜 어떻게
   **검증 방법**: docker exec ... npm test

   Counts in the WORKLOG (and CHANGELOG) are copied from the facts block that Gate D pasted (hooks/report_facts.py), or from a fresh run of it — never re-counted from memory. Write N/M instead of 「모두·전부」.

2. Long-form archive — newly create (copy) the session Gate A~E body to <archive_path>/ARCHIVE_날짜_세션ID.md (archive_path from .claude/harness-answers.yml — the archive files go directly in it). Make the first line final_status: ✅E (YYYY-MM-DD): gate-a and doc-cleanup read it, and it is the last record of completion once doc-cleanup removes the session's ✅E row from the index.

   Separation of responsibility (SRP):

   • Gate E's responsibility: create the new archive file + update the plan document(s) (tier-aware, see SKILL_DETAIL.md §Plan-Doc Update Pattern) + SESSION_INDEX + CURRENT_SESSION dashboard.
   • Gate E's non-responsibility: do not delete the ${CURRENT_SESSION_FILE} body (completed Gate A~D blocks). When the threshold (100 lines) is exceeded, a separate /doc-cleanup SKILL slims it down.
   • Reason: Right after Gate E, the user must be able to review the Gate A~E flow as-is in ${CURRENT_SESSION_FILE}. If the body disappears, the misunderstanding 「Gate E가 안 됐나?」 arises (reflecting 2026-04-27 user feedback).
   • User guidance: After the Step 5 update, the archive path·WORKLOG path must be noted in this response's final output (securing location traceability).

2-B. Layer 2 documents

If DOC_INDEX.md exists at the target repo root → SKILL_DETAIL.md §Layer 2 Documents.

3. Error-case storage (conditional) — perform the procedure below directly in this turn.

   Judgment: Check the items below in the ${CURRENT_SESSION_FILE} Gate B~D blocks:

   • Gate C build·type·runtime failure / Gate D FIX-B·re-verification failure / Docker·environment·permission retry
   • There is "value for the next session to reuse" (excluding simple typo·one-off mistakes)

   → If there is no target, output "오류 기록 대상 없음 — 생략" and proceed to Step 4.

   Canonical location (managed independently per repository) — the target repositories are listed in .claude/harness-answers.yml → code_repos (SSOT, shared with error-topics-guard.py). For each entry, the path is {repo}/docs/rules/error_topics/. If .claude/harness-answers.yml → error_topics_path is set, record there instead (relative to the project root); error-topics-guard.py checks that one directory and code_repos is not required.

   If code_repos is absent or empty → output "code_repos 미설정 — 오류 기록 경로 없음. harness-answers.yml에 설정하세요" and proceed to Step 4. Do not reuse the "오류 기록 대상 없음 — 생략" wording above: that one means this session produced no error worth recording, whereas this one means the recording path itself is unconfigured. Emitting the same line for both makes a configuration gap read as a normal, healthy session — the operator would keep seeing green while nothing is ever recorded.

   • Each folder's README.md is the topic index (canonical). Do not write to the ledger ../error_analysis.md.
   • Docs-only repositories (no application code) are not code_repos entries → record in the error_topics/gate_process.md of the code repository that that session worked on.

   Topic file mapping (common to every code repository):

   File	Tag	Target error
   gate_process.md	PROC	Gate approval·procedure·「구현」 interpretation·after-the-fact retroactive
   runtime_env.md	ENV	Docker/container/npm·gradle·pytest/lockfile/permission/path
   git_commit.md	PROC	commit message·git operation
   testing.md	TYPE VERIFY LOGIC	type·build·test failure·CI verification
   security_schema.md	SEC API	XSS·token·axios·API contract·DB schema

   If the topic does not fit the existing 5 files, create a new topic file + add 1 row to that repository's error_topics/README.md table.

   Append format (append as a date section at the bottom of the relevant topic file):

   ## [YYYY-MM-DD] 세션ID — 한줄 요약
   - **발생 Gate**: B / C / D
   - **적용 조건**: 다음 Gate A 가 이 교훈을 꺼내야 할 상황 1줄 (「~할 때」 — 파일·명령·기술 이름을 넣는다)
   - **증상**: (로그·메시지 핵심 1~3줄)
   - **근본 원인**: 무엇이 왜 틀렸는가
   - **해결**: 파일·라인 포함 변경점
   - **재발 방지 규칙**: 다음 세션이 지켜야 할 1줄 규칙
   - **근거**: 세션ID · 실행한 명령과 그 출력 발췌 (또는 커밋 해시) — 1회 관찰이면 「1회 관찰」이라고 쓴다
   - **채택한 변경**: 훅 / 시험 / 스킬 문구 / 없음(교훈만)
   - **검증**: 모델 · 날짜 (예: `claude-opus-5-5 · 2026-10-21`)
   - **상태**: 유효 (뒤에 대체되면 이 줄만 「대체됨 → [날짜] 세션ID」로 바꾼다)
   - **범위**: 프로젝트 (하네스 자체의 결함으로 보이면 「엔진 후보: 이유 1줄」)

   error-topics-guard.py accepts the entry only when 적용 조건 and 근거 are filled — a title line alone no longer counts. The Gate A lesson lookup (gate-a/lessons_lookup.py) matches the next task against 적용 조건 and shows 재발 방지 규칙, so write both for the next reader, not as a diary.

   Recording rules (from recursive harness-improvement research — a lesson without execution evidence pollutes every later lookup):

   • No entry is a valid answer. One-off typos and cases with no reusable cause stay 「오류 기록 대상 없음 — 생략」.
   • One cause, one entry. If the same cause already has an entry, append a dated - **재발**: [YYYY-MM-DD] 세션ID — 무엇이 달랐나 line to it instead of a new entry. Two or more 재발 lines on one entry → propose a hook or test in the next Gate A (a rule that keeps recurring as prose belongs in a device).
   • Do not credit a lesson for a session that went well. A success is not evidence that a lesson worked; only a run where the lesson changed what happened is.
   • Append only. Never rewrite or "tidy" a topic file as a whole — edit only the 상태 line of an older entry.
   • 범위 defaults to 프로젝트. Mark 「엔진 후보」 only with a one-line reason; promotion into the harness engine is reviewed in batches at /audit or release time, never per entry.

   No creating a new document per session — always append to an existing topic file.

4. FIX-B / DEP handoff — process Gate C's FIX-B·DEP items at the source in the same turn:
   • FIX-B item → register in the plan document (tier-aware, see SKILL_DETAIL.md §Plan-Doc Update Pattern) or as a next-session Gate A candidate
   • Next-session decision → record in the ${SESSION_INDEX_FILE} YAML next_action field
   • ${SESSION_INDEX_FILE} YAML sessions_since_audit += 1
   • ※ The session-status ✅E flip is performed in bulk at Step 5, not this step — preventing Step 4/5 duplication (GATE-E-ENFORCE-1)
   • ⛔ No counter value in prose (AUDIT-COUNTER-STALE-FIX-1): Do not copy the sessions_since_audit number or the =N → /audit 권장 phrase into the next_action·priority_note·${CURRENT_SESSION_FILE} 「다음 행동」 prose. Whether to recommend audit is announced by ② below, which reads the canonical YAML and outputs only in this response (a number baked into prose goes stale immediately after the audit reset → misleads the next session. The same recurring incident is recorded in the SESSION_INDEX YAML comment). If a recommendation must be left in prose, only the qualitative expression 「⚡ /audit 권장(정본 YAML 기준)」 without a number is allowed.

4-B. §5 handoff retrieval (conditional) — If there is an item pulled into this session's scope from §5 at Gate A 0-A, confirm the processing trace and delete that line: plan_tier: "2" (or field absent) → <master_plan_file> §5; plan_tier: "1" → <single_plan_file>'s handoff-notes section.

• If there is no pulled-in item, skip this step.
• The 「⚠️ 영구 기록」「✅ 결정사항 영구 기록」 subsections are not retrieved at Gate E (absolute preservation).
• The retrieval is performed together in this response turn.

4-b. Session ledger line (every session, either lane) — run python3 "${CLAUDE_PLUGIN_ROOT}/hooks/session_ledger.py" append --base <base commit of Gate D's facts block> --model <your model ID> [--finding "…"]... and paste its one-line output into this response.

• --finding: one per thing the user pointed out or corrected in this session — a wrong number, a missed file, an error a 「대조 검증」 turned up — one line each. None → leave it out (records 0). Never drop a correction to look better: this is the measure the harness is improved from.
• The script reads everything else itself (lane, Gate 진행, markers, diff counts, engine version). If it exits non-zero (no archive_path), continue Gate E and say so; it never blocks the session.

5. Plan-doc ✅E status flip (same response turn) — update all applicable plan document(s) below to ✅E (tier-aware, see SKILL_DETAIL.md §Plan-Doc Update Pattern). The status flip is this step's single responsibility (no duplication with Step 4):

   (a) Plan document(s) — plan_tier: "2" (or field absent) → <detail_plan_file> §7, that session's row status → ✅E (날짜, 핵심지표); plan_tier: "1" → <single_plan_file>'s matching ## Phase N session entry → ✅E (날짜, 핵심지표).

   (b) ${SESSION_INDEX_FILE} YAML — that session's gate: → ✅E (...)

   (c) ${CURRENT_SESSION_FILE} — update all of ①②③ below (PROC violation if even one is omitted):

   • ① Header block > **현재 상태**: → ✅E 완료 (날짜)
   • ② Dashboard table | 현재 Gate | → ✅E 완료
   • ③ Dashboard table | Gate 진행 | row → the last E☐/E⏳ to E✅

Enforcement device: Omitting this Step 5(c) is detected by gate-e-sync-guard.py (Claude Code Stop hook) as a SESSION_INDEX ↔ CURRENT_SESSION ✅E mismatch, blocking response termination (GATE-E-ENFORCE-1). Splitting content output and document update across different turns is a PROC violation.

This Gate response's mandatory final output

After completing the entire Gate E procedure (WORKLOG + archive + plan document(s) update), output the block below at the very end of the response. Omitting it or replacing it with other content is a PROC violation.

Output order: ① Gate E 산출물 위치 → ② 문서 상태 요약 → ③ audit 권장 여부 → ④ 세션 완료 안내

① Gate E deliverable location — After Gate E completion, output the deliverable paths explicitly so the user can trace the result. This is the key output for preventing user misunderstanding, so do not omit it:

── Gate E 산출물 위치 ──────────────────────
  archive (장문 본문) : <archive_path>/ARCHIVE_YYYY-MM-DD_{세션ID}.md
  WORKLOG            : <worklog_path>/YYYY-Www.md (line N~M)
  문서 갱신 (✅E)     : ${SESSION_INDEX_FILE} · ${CURRENT_SESSION_FILE} 대시보드 · {plan_tier: "2"인 경우 detail_plan_file §7 / plan_tier: "1"인 경우 single_plan_file 해당 Phase}
  ${CURRENT_SESSION_FILE} : 본문(Gate A~D 블록) 보존됨 — 슬림화는 별도 /doc-cleanup 호출 시 수행
────────────────────────────────────────────

Explicitly stating that the ${CURRENT_SESSION_FILE} body is preserved makes the user aware that 「Gate E 결과를 그대로 검토 가능」.

② Document status summary — Right after Gate E completion, measure the applicable plan-doc line counts (row set per harness-answers.yml → plan_tier, see doc-cleanup/SKILL.md §Step 0-B). Output in the format below:

── 문서 상태 ──────────────────────────────
  ${CURRENT_SESSION_FILE}          : N줄  (임계값 100줄) ✅ / ⚠️ 초과
  ${SESSION_INDEX_FILE}            : N줄  (임계값  80줄) ✅ / ⚠️ 초과
  {plan_tier: "2" 행 집합}
  <master_plan_file>          : N줄  (임계값 450줄) ✅ / ⚠️ 초과
  <detail_plan_file>          : N줄  (임계값 700줄) ✅ / ⚠️ 초과
  {또는 plan_tier: "1" 행 집합}
  <single_plan_file>          : N줄  (임계값 <single_plan_threshold>줄) ✅ / ⚠️ 초과
────────────────────────────────────────────
  ⚠️ 초과 항목 있음 → `/doc-cleanup` 실행을 권장합니다.
  (또는 모두 이하) → 문서 상태 정상
────────────────────────────────────────────

③ audit recommendation judgment (SESSION_INDEX YAML single source):

Judge based on the sessions_since_audit field of the ${SESSION_INDEX_FILE} YAML header (the value right after += 1 at Step 4). The judgment·recommendation is performed only in this response output, and the counter number is not recorded in persistent-document prose (same principle as Step 4 「카운터 값 서술 금지」 — the canonical YAML is the sole source).

• sessions_since_audit ≥ 3 → output recommendation
• last_audit_date field absent (first time) → output recommendation
• Chain-transition·priority-change point (e.g. last ✅E of the MEETING-ALIGN chain → entering the next chain, MVP Phase transition, the plan document's priority-table update — <master_plan_file> §2 under plan_tier: "2", or <single_plan_file>'s equivalent priority section under plan_tier: "1") → unconditionally output recommendation

When recommending:

⚡ 직전 /audit 이후 {sessions_since_audit}개 세션 완료 — `/audit` (방향성 점검) 호출을 권장합니다.

If not applicable, omit this block.

④ Session completion guidance:

---
**세션 완료**: 다음 세션은 `${SESSION_INDEX_FILE}`의 `next_action` 항목을 확인하세요. 새 작업 시작 시 `/gate-a` (Gate A 계획)로 시작합니다.