0 Fork 0

Files

T

ahnyongjooandClaude Sonnet 5.5 964a841de1 chore(rebar): Pier_T_rebar 작업 폴더 초기 구성 및 외부 의존 파일 통합

- Code\rebar_pipeline, review_pipeline, pier-program을 정션에서 실제 폴더로 전환
- Code\rhino_mcp 및 CLAUDE_rhino배경.md 추가, .mcp.json은 PYTHONPATH로 새 위치 사용
- pier-program 내부 .git 제거(이력은 backup\pier-program_20261028.bundle에 보관)
- worktree 가이드 반영(CLAUDE.local.md, HANDOFF.md)
- D:\Rhino-MCP 경로 참조를 새 위치로 치환

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

2026-10-28 11:20:18 +09:00

7.4 KiB

Raw Blame History

name, description

name	description
tea-verify	전역 지침 Step 3 검증 — 검증 기재 원칙, V1~V16 체크리스트와 상세 판정 기준, 보정된 신뢰·검증 독립성(R9). 모든 Task의 Step 3 착수 시, 또는 산출물을 승인·판정할 때 반드시 읽는다.

검증 (Step 3) · 보정된 신뢰 (R9)

전역 지침 스킬 — 코어 taskexecutionagent.md(v0.3.01) [스킬 지도]에서 호출된다. 담긴 조항: Step 3, R9 아래는 v0.2.08 이전 코어의 조항 원문이다(무손실 이관). 조항 ID·번호는 코어와 공통이다. 코어의 요약과 어긋나 보이면 이 원문을 따르고, 그 사실을 [Step 5] 비고에 적는다.

────────────────────────── [Step 3] Verify (검증) ──────────────────────────

수행: 아래 체크리스트의 각 항목에 대해 PASS / FAIL / N/A를 판정한다. SIMPLE·FAST 경로에서도 ★ 표시 항목은 반드시 검증한다.

검증 기재 원칙 (v0.1.1 신설) — 아래 3가지를 지키지 않은 판정은 무효로 본다.

검증 방법을 명기한다. 무엇으로 어떻게 확인했는지(스크립트·명령·육안 등). 사용한 스크립트는 [F3]에 따라 Code/에 보관한다.
모집단과 표본 수를 명기하고 전수와 표본을 구분 표기한다.
- 전수: PASS(전수 59/59) / 표본: PASS(표본 8/59)
- 표본 검사 결과를 전수 PASS로 표기하지 않는다.
존재 검사와 기능 검사를 구분한다. "파일이 있다"는 "쓸 수 있다"를 의미하지 않는다. 산출물이 실제로 사용 가능한 상태인지 별도 판정한다.

FAIL은 FAIL로 기록한다. 자체 판단으로 "실질 무결"이라 보더라도 판정은 FAIL로 두고 [Step 4] 보정 표에서 사유와 함께 처리한다. FAIL을 총평에서 PASS로 흡수하지 않는다.
검증기 자체를 의심한다. FAIL이 반복되면 데이터보다 검증 로직의 결함 가능성을 먼저 확인한다.

검증 체크리스트:

#	검증 항목	필수
V1	업무 목표 충족 여부	★
V2	기대 산출물 형태/포맷 일치	★
V3	문서 근거 누락 없음
V4	수치/데이터 정합성 (파일명↔이력 버전 일치 포함)	★
V5	시각 자료(표/도표) 반영 완전성
V6	논리적 비약 또는 모순 없음
V7	사용자 제약 조건 준수
V8	산출물 저장 규칙 준수 (DOC/.md/유형별 분리)	★
V9	OUTPUT 경로 실재성 확인 (`ls` + 버전·핵심항목 대조)	★
V10	수용 기준 충족 ([ref: Step 1 - 판정 항목])	★
V11	산출물 가동 가능성 (즉시 사용 가능한 상태인가)	★
V12	원본 무결성 (변경하지 않은 대상의 지문 불변, [F13])
V13	검증 스크립트 보관 ([F3])
V14	검증 독립성 (생성≠검증. 자기검증이면 그 사실 명시, [R9])	★
V15	자율성 등급 준수 (HITL 고정 5항 대조 + 완화 시 승인 확인, [G1-2])	★
V16	오케스트레이션 규약 준수 (`[ORCH-TRIGGER]` 해당 시 필수, [G7])	★

V9 상세: 파일 존재 확인만으로는 부족하다. ① 경로에 파일이 있는가 ② 파일명 버전이 기재와 일치하는가 ③ 본문에 이번 Task의 핵심 신설 항목이 실제로 포함되어 있는가 — 3가지를 함께 확인한다. (사고 사례: "실재성 확인 완료"로 기재됐으나 파일명만 확인하고 내용·버전을 대조하지 않아 실제로는 구버전만 존재)
V15 상세: ① [G1-2] HITL 고정 (1)~(5) 각 항목의 해당 여부를 대조표로 기재한다 ② 해당 단계를 다른 등급으로 표기하지 않았는지 확인한다 ③ 등급을 완화한 단계가 있으면 사용자 승인 근거를 함께 기재한다. 대조표 없는 V15 판정은 무효로 본다. Agent가 스스로 정한 등급을 스스로 PASS 판정하는 것은 검증이 아니다. ([R9])
V16 상세: 트리거 해당 항목, 위임 깊이·재위임·병렬 수의 [G7] 상한 준수, tea-orchestration O9 주체별 흐름표 기재를 대조한다. 트리거 비해당이면 N/A.

FAIL 항목 존재 시: → 해당 항목의 문제점과 수정 방안을 구체적으로 기술한다. → 사용자 판단이 필요한 FAIL은 판정표 중간이 아니라 응답 최하단 확인 블록에 모아 제시한다. ([R10])

→ STOP (FAST 모드는 생략하되 판정표는 반드시 기재)

R9. 보정된 신뢰와 검증 독립성 (Calibrated Trust) — v0.2.00 신설

사람–AI 협업은 정반대의 두 방향으로 무너진다. 어느 쪽도 방치하지 않는다.
- 과신 (automation bias): AI가 대체로 맞으면 사람의 검토는 형식이 된다. 읽지 않고 승인하는 순간 [G1-2]의 HITL은 문서에만 존재하며, 사람이 들어가 있다는 사실 자체가 안전하다는 착각을 만든다.
- 불신 (algorithm aversion): 한 번 틀린 AI를 통째로 배제하면 잘하는 영역의 이득까지 함께 버린다.
검증 독립성 — [Step 3]은 생성 주체가 스스로 하는 자기검증이라는 구조적 한계를 갖는다. 아래를 적용한다. (1) 문건 산출물·정량 결과는 생성과 검증을 분리한다. 서브에이전트 위임([SECTION 7]) 또는 별도 세션에서 검증하며, 검증자에게는 결론이 아니라 원자료와 판정 기준을 준다. (2) 분리가 불가능하면 그 사실을 [Step 3] 비고에 자기검증으로 명시한다. 자기검증 결과는 독립 검증으로 계상하지 않는다. ([SECTION 5-7]) (3) PASS를 선언하기 전에 "무엇이 나오면 FAIL인가"를 먼저 쓴다. 반증 조건 없는 PASS는 판정이 아니라 소감이다.
승인 근거 1줄 의무 — 산출물을 승인할 때 확인함·OK만으로 기록을 남기지 않는다. 무엇을 어떻게 확인했는지 한 줄을 함께 남긴다.
수정률을 기록한다. AI 산출물을 사람이 얼마나 고쳤는지(수정 항목 수 / 주요 수정 사유)를 [Step 5] 로그 비고에 남긴다. 수정률이 지속적으로 높은 작업 유형은 [R8] 수용 기준 또는 [G1-2] 등급을 재조정한다.
AI에게 판단을 위임할수록 사람의 판단 근거를 문서로 남겨야 한다. 근거 없는 승인이 누적되면 조직에 남는 것은 산출물뿐이고 판단 능력은 남지 않는다.

7.4 KiB Raw Blame History

검증 (Step 3) · 보정된 신뢰 (R9)

7.4 KiB

Raw Blame History