Files
Pier_v1/DOC
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
..

DOC 폴더

Task Execution Agent이 생성한 모든 산출물(문건) 을 저장하는 폴더입니다.

본 문서는 .claude/taskexecutionagent.md v0.3.01의 [F1]·[F3]·[F5]·[F6]에 종속됩니다. 충돌 시 정본이 우선합니다.

저장 형식

  • 모든 문건은 Markdown(.md)으로 저장합니다. (아티팩트 형태 금지)
  • 표 형태로만 표현 가능하여 불가피하게 시트가 필요한 경우에만 .xlsx로 저장하되, 생성 전 사용자 컨펌을 받습니다.
    • 단, 프로젝트 성격상 xlsx가 기본 산출 형식인 경우(수량산출 등) 프로젝트 단위 예외를 context-migration에 1회 등재하고 이후 건별 컨펌을 생략합니다.
  • 코드 파일(.py·.js·.html 등)과 바이너리(.pptx·.dxf 등)를 DOC 하위에 두지 않습니다. → Code/ ([F3])
  • DOC 루트에는 README 외의 산출물을 두지 않습니다. 백업·복사본·임시 파일은 backup/·temp/로 이동합니다.

폴더 구조 — 유형축 표준 ([F1])

DOC/
├── 01_기획/
├── 02_분석/
├── 03_설계/
├── 04_실행/
├── 05_검증/
├── 06_보고서/
└── 99_기타/
  • 유형축이 상위입니다. 주제(공종·아이템 등)별 구분이 필요하면 2단계로 둡니다: DOC/<유형>/<주제>/
  • 주제축과 유형축을 같은 계층에 혼재시키지 않습니다.
  • 번호는 결번 없이 연속으로 쓰며, 위 7종 외로 유형 접두어를 임의 증식하지 않습니다.

파일명 규칙

[유형]_[핵심주제]_[YYYY-MM-DD]_v[버전].md

예: 보고서_2분기실적분석_2026-08-25_v0.1.00.md

  • 폴더 루트 접두어 금지: 폴더가 존재하면 파일명에 폴더 경로/폴더명을 붙이지 않고 해당 폴더 안에 순수 파일명으로만 저장합니다. (예외 처리는 [F7])
  • 파일명에 담당자명·최종)·(수정본) 등을 삽입하지 않습니다.
  • 파일명·폴더명은 한국어를 쓰되 공백·괄호·특수문자를 넣지 않습니다. (영문 kebab-case 주제명 금지, [G2])
  • 버전 토큰은 파일명당 1개만 허용합니다. 대상 산출물의 버전을 표기해야 하면 [핵심주제] 안에 하이픈으로 붙입니다. 예: 진단보고서_모듈A-v0.1.0-문제점및개정내역_2026-08-25_v0.1.00.md

버전 관리 ([F5])

자릿수별 승급 권한

버전 자릿수는 변경의 크기가 아니라 문서가 누구에게까지 나가는가를 나타냅니다.

자리 표기 승급 조건 승급 권한
PATCH (세 번째) v0.1.xx 기본값. 수정·보완·오류 정정·조항 신설·구조 변경 등 공유 범위가 그대로인 모든 개정 Agent 자율
MINOR (두 번째) v0.x.00 내부 공유용으로 발행할 때 사용자 요청 시에만
MAJOR (첫 번째) vx.0.00 외부 공유용으로 발행할 때 사용자 요청 시에만
  • 개정은 언제나 PATCH가 기본값입니다. v0.1.00을 고쳤으면 v0.1.01입니다.
  • Agent는 MINOR·MAJOR를 스스로 올리지 않습니다. 분량이 크든 장을 신설했든 그 자체는 승급 사유가 아닙니다.
  • "버전 올려줘"라고만 지시하면 PATCH로 올리고, 내부·외부 공유 목적이면 [CLARIFICATION NEEDED]로 확인한 뒤 승급합니다.
  • 승급 시 하위 자리는 00으로 초기화합니다. v0.1.07 → (내부 공유) → v0.2.00 → (외부 공유) → v1.0.00
  • MINOR·MAJOR 승급 시 그 근거를 변경 이력 비고에 남깁니다. 근거 없는 승급은 [Step 3] V4 FAIL입니다.

상황별

상황 버전 승급 주체
최초 작성 v0.1.00 Agent
내용 수정·보완·오류 정정 v0.1.01, v0.1.02 … Agent
장·절·시트·열 신설 등 구조 변경 v0.1.03 … Agent (PATCH로 처리)
내부 공유용 발행 v0.2.00 사용자 요청
내부 공유본 수정 v0.2.01 … Agent
외부 공유용 발행 (최종본) v1.0.00 사용자 요청
최종본 수정 v1.0.01 … Agent
  • PATCH는 두 자리 제로 패딩을 씁니다 (v0.1.09 → v0.1.10). 패딩이 없으면 v0.1.10이 v0.1.9보다 앞에 정렬되어 최신본 식별이 어긋납니다.
  • 하이픈·알파벳 접미사 금지 (v0.1.9-5, v0.1.15b). 버전 뒤에 자유 문자열도 붙이지 않습니다 (v0.3.1최종확인 등).
  • 버전을 올리지 않고 덮어쓰지 않습니다. 사용자가 그렇게 지시하더라도 [CLARIFICATION NEEDED]로 이력 소실 위험을 고지한 뒤 확인을 받습니다.
  • 구버전은 삭제하지 않고 보존하며, 정리가 필요하면 backup/으로 이동합니다.
  • 파일명 버전과 본문 변경 이력 표 최신 행의 버전은 항상 일치해야 합니다. 불일치는 [Step 3] V4 FAIL입니다.

변경 이력 규칙 ([F6])

모든 DOC 산출물은 제목 바로 아래에 변경 이력 표를 포함합니다. 버전업마다 행을 오름차순으로 누적하며(최신 행이 맨 아래), 기존 행을 삭제하지 않습니다. 수정자는 [F4]에 따라 담당자명으로 기재합니다. (IP로 기재하지 않습니다.)

버전 수정일 수정자 주요 변경 내용 비고
v0.1.00 2025-06-05 홍길동 신규 작성 최초 버전
v0.1.01 2025-06-06 홍길동 2.3 항목 문구 수정 내부 검토용
v0.2.00 2025-06-07 김철수 초안 검토용 팀 공유 검토 요청
v1.0.00 2025-06-09 김철수 최종본 확정·대외 배포 공식 배포

적용 제외: prompt/ 로그. 로그는 append-only 감사 기록이므로 개정 이력 개념이 성립하지 않습니다.

타인 명의 문서 정정 시에는 정정자·정정일·근거를 병기합니다. 예: > [정정 2026-08-25 / 홍길동] 원문은 A로 기재했으나 B가 맞다. 근거: …