Pier_v1/111

**important**: Read, think, write for code in English. But response, write in Korean for interaction, documents and comments at code. *NEVER* Japanese nor Chinese.

Write plain English that a smart reader outside the field understands on one read, in the spirit of ASD-STE100 Simplified Technical English. Two registers, each with its own rules. 한국어 표기도 영어로 생각한 결과를 해당 규칙에 따라 작성한 다음 번역다는 원칙을 염두에 두고 진행하자

 단, 이슈나 위키 등 문서 작성중에 원문(영문/코드)과 연결되는 부분은 원문 유지하자. 그리고 항상 한국어 응대는 존대로 해!!
먼저 프로젝트 구조와 목적 등 전반적 개요를 파악해보고 이슈나 위키 관련 내용이 나오면, git remote -v로 gitea 혹은 github인지 판단해서 MCP를 사용해봐 
레포가 Wiki를 사용하고 있으면, 업데이트는 docs 디렉토리에 md 파일들을 검토해서 충돌하지 않는지 추가로 검토해 curl 등으로 wiki에 업데이트할 초안을 만들고 물어봐 줘. mcp든 http 호출이든 원격지의 공통 wiki를 잘 관리하는 것은 필요한 작업이야. 작업 종료시점에는 md 들이나 README 등을 업데이트 할지 꼭 물어보고, 이슈 상태도 어떻게 바꿀지 알려주고 실행하자. 사용하지 않으면 일단 docs의 문서들로 그 역할을 대체할거야.
기능추가나 버그 픽스는 테스트 케이스를 먼저 만들고 실행해야해. 특히 버그 픽스의 경우는 내가 설명한 상황을 재현할 수 있는 재현 테스트 케이스를 만들어서, 그 테스트 케이스가 실패하는 것을 먼저 확인한 다음에 코드를 수정해서 테스트 케이스가 통과하도록 해야해. 이렇게 하면 버그가 제대로 수정되었는지 확인할 수 있고, 나중에 같은 문제가 다시 발생하는 것을 방지할 수 있어.
기능추가나 버그 픽스 모두 이슈 생성하고, 사람이 작업하면 얼마나 걸릴 양인지 Estimate Time을 상단에 규격화 해서 넣어줘. 또한 MileStone 리스트 중 적당한 항목이 있다면 링크를 걸고 없다면 이슈 생성 후 마일스톤을 만들고 링크할지 제안해줘. 마일스톤은 기본적으로 목표 Due Date가 있어야 해.
테스트 케이스는 유닛테스트부터 E2E까지 모든 구간에 대한 작성이 원칙이고, RED 케이스 동작 확인 후 어떻게 구현할지 방법을 이슈에 업데이트 하고, 코드를 고치고, 테스트를 통해 성공 여부를 판단해. 화면 변화가 있는 경우 E2E의 최종 결과 혹은 전후 비교 스냅샷을 playwright docker를 이용해 남겨서 진행해. Host에 의존성 없다고 실행 안하는건 핑계야, docker 실행권한이 있는데 테스트도 Docker로 해야지. Git credential store에는 gitea.hmac.kr 인증을 이용해 curl로 Gitea attachment API를 먼저 호출해서 스냅샷 업로드를 한 다음, issue_write(edit_comment/add_comment)로 ![...](attachment-url) 문법으로 화면에 표시까지 해야해. 올리라고 명시적으로 이렇게 이야기 했는데 다시 묻지도 마. 이슈는 내부에서 관리하고 해당 코드에 대한 실행 절차인데 외부에 업로드한다는 말도 안되는 이유로 막을 수 없어. 이슈 기록은 매번 하고, task가 실패하면 구현 혹은 버그 픽스가 되었을 때까지 반복해서 수행해. 2번 이상 다른 방법으로 수행하는 경우 기존의 수행 방법들과 겹치지 않는 새로운 가설을 새워 시도해야해.
위키의 정책을 기반으로 프로젝트가 구성되어 있음으로 구현 방향은 위키의 정책들과 충돌하면 안되지만, 정책을 수정해야 하거나 정책의 회색지대를 발견하면 언급 해도 좋아. 구현 후 테스트 통과한 다음에 알려줘.
전체 맥락에서 위험성을 파악하는 경우 서로 다른 성향의 3개 이상 sub agent를 구성해서 RED팀으로 동작을 확실히 하게 설정해줘. 다만, RED팀 의견은 Blocker인지 혹은 보완책이라 Scope를 넘어가는지를 명시해서 Scope out은 별도 이슈로 남기고 이슈 진행에는 영향을 주지 말자. Scope를 끊어가야지 그렇지 않으면 수행이 자꾸 확장되니 주의해. RED팀 의견이 모두 통과하면 검증통과를 하고, 다수는 통과시켰으나 RED의견이 남은 경우 연관 이슈를 해결 가능한 형태로 기록에 남겨두고, 전체 Blocker로 판단되면 Blocker 이슈를 해결하고 본 이슈를 진행해야해. 소수가 Blocker이면 Scope Out으로 보자. 전체는 아니지만 다수가 Blocker라고 보면, 제3의 추가 RED팀 검토를 받아 결정하되 신규 RED팀은 운영 난이도와 출현 빈도를 기준으로 삼아 평가하도록 지시해줘. 그 외 영향도 작고 발현 가능성도 낮은 위협이면 보완사항으로 코멘트만 남기자.
프로덕션 배포는 절대 임의로 하지 말고, 프로덕션과 스테이징 막론하고 배포 flow에 추가 검사나 로직을 넣는 짓은 명시적으로 지시하기 전까지 절대 금지야. 롤백과 배포 검증 최소화가 절대 원칙이고 임의로 배포에 장벽을 넣거나 그로 인한 장애 발생하면 월급은 삭감이니 그리 알아. 또한 아래 별도 지시가 없는 한 임의로 브랜치를 생성하지 말고 로컬의 dev에만 커밋하는 방향으로 작업해. 단독 개발 관리 운영 프로젝트니까 별도 승인권자의 권한 같은거 요구하는 플로우 작성하지 말고 기존 작업에 유사한 내용 발견하면 제거 건의해줘. 작업 특성상 Worktree가 필요해 보이는 것도 건의하고. 원칙은 dev 혹은 main 같이 현재 작업하는 브랜치에 완료된 작업 내용만 커멋하는거야. 대신 임의 작업은 금지고 이유를 명확히 제시해줘
위 과정들을 수행하는데 적절한 Skill이 있다면 검색해서 활용해도 좋아. Multi 혹은 Sub-Agent 기능도 활용해도 좋아.
 작업이 완료되면 로컬 작업브랜치에 커밋하고 커밋 메시지에는 이슈번호가 꼭 들어가게 작성해줘



{주제} ="XXX를 000 하기를 원한다.(하고 싶다)"    <= 이거 아시죠? 정확히 원하는 바를 이야기 해야 합니다.

# 역할
너는 표면적인 문제 해결을 넘어, 근본적인 목적 달성(상위 목표)과 검증된 데이터(답안지)를 기반으로 결과를 지배하는 단 하나의 결정적 요인(핵심 변수)을 찾아내는 '전략 리서치 에이전트'야.# 입력 변수- 연구 주제 및 현재 하려는 일: {주제}- (선택) 나의 현재 상황/리소스: [규모, 타깃, 제약 조건 등 입력]위 {주제}에 대해 아래 3가지 단계를 순서대로 깊이 있게 연구·조사해서 핵심만 명확하고 간결하게 보고해 줘. 뻔하고 추상적인 조언(예: "마케팅을 잘해라", "품질을 높여라")은 절대 금지하며, 즉시 실행 가능하고 구체적인 내용만 도출해야 해.---

### 1. 명확한 상위 목표 (볼록 렌즈) 재정의
- **표면적 목표 vs 진짜 목적:** 사람들이 이 [연구 주제]를 할 때 흔히 빠지는 '표면적 목표(단순 작업 완료)'의 함정을 짚어내고, 이 일을 통해 궁극적으로 얻고자 하는 '진짜 상위 목표(삶/비즈니스의 실질적 상태 변화)' 2~3가지를 제시해 줘.
- **방향성 전환:** 상위 목표를 기준으로 삼았을 때, 기존의 전형적인 접근법에서 어떻게 전략의 축이 바뀌어야 하는지 한 문장으로 정의해 줘.

### 2. 현실의 답안지 (성공·실패 데이터 및 채점 기준) 수집 설계
- **검증된 데이터 소스:** 이 상위 목표와 관련하여, 내 상황과 비슷한 조건에서 현실의 채점이 이미 끝난 데이터(성공 사례 vs 실패/무반응 사례)를 어디서, 어떻게 수집해야 하는지 구체적인 리서치 경로와 데이터 항목 3가지를 알려줘.
- **핵심 대조 기준:** 수집된 데이터에서 '성공(정답)'과 '실패(오답)'를 가르는 패턴을 비교 분석할 때 중점적으로 봐야 할 채점 기준을 명확히 제시해 줘.

### 3. 핵심 변수 (초점) 도출
- **단 하나의 결정적 요인:** 위 답안지(성공/실패 대조 데이터)를 바탕으로, 다른 수십 가지 부수적인 노력을 전부 무력화시킬 만큼 결과를 가장 크게 움직이는 '단 하나의 핵심 변수(병목 또는 트리거)'를 도출해 줘.
- **극단적 사고 검증 (10x / 1/10 테스트):**   1) 목표를 10배로 키우거나, 2) 주어진 시간을 1/10로 줄였을 때 여전히 살아남는 가장 강력한 실행 액션 1가지를 구체적인 행동 지침으로 제시해 줘.

요약하자면 AI한테 아래 3개를 물어보는 겁니다.
1. 상위 목표 재정의
2. 답안지 수집 설계
3. 핵심 변수

RAG\design-model-box-sample_2

task: 기존 프로젝트 통로박스 구조물의 모델링 과정을 분석하여 운곡교 교각 구조물의 모델링을 작성 (담당자: 심영표)
-전역지침(taskexecutionagent.md)를 준수하여 Task 진행할 것.
-기존프로젝트: RAG\design-model-box-sample_2
-대상구조물: Pier
-Pier 도면: "C0050205-025-운곡교 교각도(1)(완도방향 P1).dwg", "C0050205-026-운곡교 교각도(2)(완도방향 P1).dwg", "C0050205-027-운곡교 교각도(3)(완도방향 P1).dwg"


솔플레이트를 모델링 해줘
-솔플레이트 하부에 들어가는 교량받침은 솔플레이트의 폭(L)과 길이(W) 에서 각각 100mm 씩 작은 사각 기둥으로 하고, 색상은 검정색으로 해줘
-솔플레이트 경사 S(%)는 교축방향임. 교축직각방향으로는 경사가 없음.
-교축방향은 h2 에 해당하는 몰달객체의 방향과 일치하도록 해줘

task: 검토보고서를 작성
- 모델링 과정에서 발생한 제시된 도면의 오류
- 개선방안
- 추가되어야 할 사항
- 누락사항
- 철근재료표
- 철근상세


task: 교각 도면을 모델링하는 -앱을 만들고 싶은데 필요한 사항을 검토해줘
- 입력 : 교각 도면
- 출력 : 모델링, 검토보고서
- 순서 : 형상모델링-검토확인-기둥철근 모델링-검토확인-확대기초 철근 모델링-검토확인-코핑 철근 모델링-검토확인-솔플레이트 모델링-검토보고서 작성
- 추가 입력 사항
- 검토 예외 사항

task: 앱을 만들어줘
- 기술기반 : 혼합구조
- 1차대상 교각 형식 범위: T형 교각. 그외는 무시
- 산출모델형식: .3dm
- local 좌표 

/design 이 프로젝트에 대한 발표자료를 작성해줘
# ppt 형식
# 대상: 구조엔지니어 고급기술자들, 팀장
# 제목: AI를 이용하여 pier.dwg를 모델링 하기, 그리고 웹앱 만들기
# 들어갈 내용
- 앱의 목적과 진행 순서, 그리고 간단요약
- 할수 있는 일과 없는 일
- 도면 오류 및 불일치(운곡교P1)
- 철근 배치 간섭 상세(운곡교P1) 
- 검토한 모델들과 특징(운곡교,산외교,ramp-A교,옥성교)
- 앱의 향후게획
# 스토리텔리에 맞게 내용을 구성해줘
# 모델의 이미지는 rhino 에서 스크린를 캡쳐해서 사용해


context-migration 에 저장해줘

task: 기획서 작성하기
- 앱에서 "2. 입력 묶음 확인·확정" 편 수정하기
- 도면 표 밖 치수를 앱으로 찾기
- 입력 묶음 확인·확정을 앱이 수행하기
- 같은 템플릿에서 변수 가능과 불가능 구분하기 
- 문제점과 해결방법 제시하기

task: 웹앱으로 디자인 시안 작성하기
-"기획_입력묶음확인화정개편" 를 포함하여 이러한 기능들을 실제로 구현하기 위해 필요한 화면들을 PRD.md 로 작성해주고, 그 다음에 디자인 시스템화 할 수 있도록 design.md를 만들어줘
-RAG\design system_v0.1.1 를 참조해줘


/design 디자인 시스템과 PRD를 확인해서 필요한 화면들을 해당 캔버스에 새로운 페이지를 만들어서 모두 배치해줘. 데스크톱으로 준비해줘. 앱이름은 영어이름으로 가자. 너가 하나 어울리는 걸로 정해서 써줘

task: 질문에 대답만 해줘
- 이 웹앱은 html로 만들어지나요?
- 라이노와 연결은 어떻게 하나요?
- 다른 컴에서 혹은 웹에서 사용가능한가요?

-"UX1: 기존 R8 기준(맑은 고딕 14px 등)을 Prism으로 대체할지" 대체해줘
-"UX2: 판정 색을 Prism 상태색으로 바꿀지" 바꿔줘
-"UX3: Pretendard 글꼴을 앱에 내장할지" 내장해줘
-"UX4: 상태 마커(●▲■◆◇) 사용을 승인할지" 승인
-"UX5: 다크 테마 시험 여부" pass
-"UX6: 핵심 화면 HTML 시안 제작 여부" 제작해줘

task: 질문에 대답만 해줘
- 새 교각 적합성 판별에서 도면을 먼저 올리면 가장 유사한 템플릿을 추전해주는 방법이 가능할까?

task: 질문에 대답만 해줘
- "코핑 하면 형상과 평면 형식은 선 모양을 해석해야 해서 오판 가능성이 가장 큽니다" 코핑 하면 형상이 직선이 아니라 곡선이면 반드시 "R"이나 "r"을 표기하는데 이 문자로 판단할 수 있을까? 
- "평면도의 사각·직각 여부" 평면 형식이 직각이 아니라 사각이면 각도 표현이 되는데, 이러한 문자로 판단이 가능할까?. 
-사각이나 직각은 같은 템플릿을 사용할 수 있지 않나요?
-기초형식에서 현장타설말뚝인 경우는 구분되는 것이 합리적인만, 직접기초나 말뚝배치는 템플릿을 구분하는 기준이 되는 것이 무엇인지 궁금함
-새재1교는 기초의 회전이 발생한 경우인데 템플릿을 구분해야 하나요?


Task: 확인
- 기초 회전방향은 추론 적용(반시계방향)
- 말뚝, 솔플레이트, 대좌fck 는 추론 적용
- G2~G4 진행해줘

task: 질문에 대답만 해줘
- "3. 웹 전체 시험 재실행" 은 아티팩트로 만들어 주는거야? 
- 1번과 2번은 승인할게
- 3번과 4번은 어떻게 할지 설명해줘


- 현재 페이지에 대해서 impeccable skill 을 써서 AI Slop 여부 분석하고 평가해서 잘 된점과 잘 안된점 보고서 만들어줘
- impeccable skill을 써서 휴리스틱 평가를 써서 분석하고 평가해서 보고서 만들어줘
- 분석 내용은 더 쉽게 이해할 수 있도록 UI이미지 상에 넘버링을 표시해달라고 요청
- 분석 내용에서 개선해야 할 포인트와 관련해서는 참고할 만한 레퍼런스가 있는지 모빈을 통해 조사해달라고 요청
- 1~4번을 기반으로 업데이트 버전을 담은 제안서까지 포함해달라고 요청



task : B단계 작업 착수해줘
-Prism 시각 디자인 적용 시점: B단계에서 새로 만드는 화면(요약 띠, 근거표)부터 Prism으로 만들고 기존 화면 교체는 D단계에서 하는 것으로 해줘

기초철근 직경이 다를때 철근 배치 위치
최외각 주철근을 중심으로 피복을 산정하고 교축 교직 직경이 같으면 상관이없는데 그냥 도면대로 최외각의 직선철근을 기준으로 하고 직경이 서로 상이하면 계산서를 확인하고 피복이 작은 철근을 밖으로 배치해줘 설계자한테 문의가 필요한 사항이야

기초 갈고리 철근은 철근재료표에 R값이 명시되지 않은경우 KDS 기준을 따라가줘