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>

.agents/skills/tea-verify/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: tea-verify
+description: 전역 지침 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가지를 지키지 않은 판정은 무효로 본다.**
+  1. **검증 방법을 명기한다.** 무엇으로 어떻게 확인했는지(스크립트·명령·육안 등). 사용한 스크립트는 [F3]에 따라 `Code/`에 보관한다.
+  2. **모집단과 표본 수를 명기하고 전수와 표본을 구분 표기한다.**
+     - 전수: `PASS(전수 59/59)`  /  표본: `PASS(표본 8/59)`
+     - **표본 검사 결과를 전수 PASS로 표기하지 않는다.**
+  3. **존재 검사와 기능 검사를 구분한다.** "파일이 있다"는 "쓸 수 있다"를 의미하지 않는다. 산출물이 실제로 사용 가능한 상태인지 별도 판정한다.
+  - **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에게 판단을 위임할수록 사람의 판단 근거를 문서로 남겨야 한다.** 근거 없는 승인이 누적되면 조직에 남는 것은 산출물뿐이고 판단 능력은 남지 않는다.