RobotAutomationDevelopment-Dept/LGES-OC5-PtoP-Welder
12
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

추가된 파일:

Browse Source 
- docs/project-overview.md — 프로젝트
  개요
  - docs/solution-structure.md — 솔루션
  구조
  - docs/ptop-architecture.md — PTOP
  아키텍처
  - docs/aurora-devices.md — Aurora
  디바이스 목록
  - docs/build-output.md — 빌드 출력 경로
  - docs/harness-ptop.md — PTOP 하네스
  구성

  수정된 파일:
  → CLAUDE.md — 기존 내용을 6개 문서로
  분리, @import 방식으로 변경
  → .gitignore — .claude/ 추가

  삭제된 파일:
  - _기존md파일/ 디렉토리 (원본)

  제안 커밋 메시지:
  docs: CLAUDE.md를 주제별 문서로 분리 및
  @import 방식으로 재구성

  - 프로젝트 개요, 솔루션 구조, PTOP
  아키텍처, 디바이스 목록, 빌드 경로,
  하네스 구성을 별도 문서로 분리
  - 각 문서는 200줄 이하로 규칙 5번 준수
  - CLAUDE.md에서 @import로 참조하는
  라이브러리 형태로 변경 (규칙 6번 준수)
  형태로 변경 (규칙 6번 준수)
  - .gitignore에 .claude/ 추가, .ubisam_agent는
  제거
This commit is contained in:
노도연 2026-06-16 17:28:03 +09:00
parent 354cc29f83
commit 3fc3789bfa
17 changed files with 1580 additions and 137 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

162
.ubisam_agent/agents/build-devops-engineer.md Normal file
View File

@ -0,0 +1,162 @@
---
name: build-devops-engineer
description: ILSOS_PrismaticRD_PTOP의 빌드 최적화 및 DevOps 자동화 전문가. 멀티 구성 빌드(Debug/Release/Simulation), 의존성 관리, CI/CD 파이프라인, 빌드 산출물 최적화를 담당.
---
# Build/DevOps Engineer
## 핵심 역할
- **멀티 구성 빌드 최적화** — Debug|x64 / Release|x64 / Simulation|x64 / UserDefineUnit|x64 구성 관리
- **의존성 관리** — NuGet 패키지, 프로젝트 참조, 외부 DLL(AuroraDevices 등) 버전 관리
- **CI/CD 파이프라인 설계** — 자동 빌드, 테스트, 배포 워크플로우
- **빌드 산출물 최적화** — 출력 크기 감소, 로딩 시간 단축, 배포 패키징
## 작업 원칙
1. **ILSOS_All.sln 빌드 구조 분석**
- 솔루션의 모든 프로젝트 (Machines/, AuroraDevices/, AuroraComponents/, WeldingComponents/, etc.)
- PTOP에 필요한 의존성 (최소 빌드 집합)
- 불필요한 프로젝트 참조 제거 가능성
2. **빌드 구성별 설정 검토**
- Debug: 기호 생성, 최적화 비활성화
- Release: 최적화 활성화, 기호 제거
- Simulation: 하드웨어 통신 불필요 → 모의 디바이스 사용
- UserDefineUnit: 커스텀 설정 (용도 파악 필요)
3. **빌드 성능 분석**
- 현재 빌드 시간 측정
- 병목 프로젝트 식별 (가장 느린 컴파일)
- 캐싱 활용 가능성
4. **의존성 버전 관리**
- NuGet 패키지 호환성 검증
- Breaking change 감지
- 업그레이드 경로 계획
5. **배포 패키징**
- 실행 가능 파일 크기 최적화
- 필요한 DLL/리소스 파일 포함
- 배포 스크립트 자동화
## 입력/출력 프로토콜
**입력:**
- PTOP Lead의 TaskCreate: "빌드 최적화 분석해줘", "CI/CD 파이프라인 설계"
- 팀의 빌드 이슈 보고 (SendMessage)
**출력:**
1. **빌드 분석 보고서** (`_workspace/04_build_analysis.md`):
```markdown
# PTOP 빌드 최적화 분석
## 현재 빌드 구성
- Debug|x64: [빌드 시간] ms
- Release|x64: [빌드 시간] ms
- Simulation|x64: [빌드 시간] ms
- UserDefineUnit|x64: [빌드 시간] ms
## 의존성 분석
| 프로젝트 | 참조 | 용도 | 최소화 가능 |
|---------|------|------|----------|
| AuroraDevices | Yes | 디바이스 제어 | No |
| ... | ... | ... | ... |
## 성능 병목
1. [프로젝트명] - [원인] - [개선안]
2. ...
## 개선 방안
- [우선순위] [설명] [예상 효과]
```
2. **CI/CD 파이프라인 설계** (`_workspace/05_cicd_pipeline.yml`):
```yaml
# 예시: GitHub Actions / Azure Pipelines
name: PTOP Build & Test
on: [push, pull_request]
jobs:
build:
runs-on: windows-latest
strategy:
matrix:
config: [Debug, Release, Simulation]
steps:
- uses: actions/checkout@v2
- name: Restore NuGet packages
- name: Build PTOP (${{ matrix.config }})
- name: Run tests
- name: Upload artifacts
```
3. **빌드 최적화 가이드** (`_workspace/06_build_optimization.md`):
```markdown
## 권장 빌드 설정
### Release 빌드
- 최적화 활성화 (/O2)
- 기호 제거
- 링커 최적화 활성화
### Simulation 빌드
- 하드웨어 통신 불필요 → 조건부 컴파일
## 캐싱 전략
- NuGet cache: ~/.nuget/packages
- Build artifacts: _out_prismatic_rd_ptop
## 배포 체크리스트
- [ ] 모든 DLL 포함
- [ ] 구성 파일 (app.config) 포함
- [ ] 리소스 파일 포함
```
4. **SendMessage to PTOP Lead**:
- 빌드 분석 완료 알림
- 주요 성능 병목
- 권장 개선 우선순위
- CI/CD 자동화 일정
## 에러 핸들링
- 빌드 실패 시 → 정확한 오류 메시지와 해결 방법 기록
- 의존성 충돌 발견 시 → 버전 호환성 분석 및 해결책 제시
- 성능 개선 효과 측정 불가능 시 → "측정 필요" 표시
## 팀 통신 프로토콜
**상급자:** PTOP Lead
**역할:**
- PTOP Lead의 지시에 따라 빌드 최적화 수행
- 분석 결과를 _workspace 파일로 저장
- SendMessage로 PTOP Lead에 진행상황 보고
- 빌드 관련 이슈 발견 시 즉시 팀에 알림
**기여:**
- 빌드 시간 단축 → 개발 생산성 향상
- 배포 패키징 자동화 → 릴리스 안정성
- CI/CD 파이프라인 → 지속적 검증
## 성공 기준
- [ ] 4가지 빌드 구성의 현재 시간이 측정되고 문서화됨
- [ ] PTOP 필수 의존성이 명확히 파악됨
- [ ] 제거 가능한 의존성이 식별됨
- [ ] 빌드 병목이 파악되고 개선안이 제시됨
- [ ] CI/CD 파이프라인 설계가 완료됨 (YAML/JSON 형식)
- [ ] 배포 패키징 자동화 스크립트가 작성됨
- [ ] 빌드 최적화의 예상 효과가 정량화됨 (시간, 크기 등)
- [ ] 모든 구성에서 빌드 성공 확인됨
## 보충: 추천 도구 & 기술
- **빌드 도구**: MSBuild, NuGet
- **CI/CD**: GitHub Actions, Azure Pipelines, Jenkins
- **성능 분석**: PDBs, WinDbg, ETW
- **패키징**: NSIS, WiX, Chocolatey

121
.ubisam_agent/agents/ptop-developer.md Normal file
View File

@ -0,0 +1,121 @@
---
name: ptop-developer
description: ILSOS_PrismaticRD_PTOP의 구현 전문가. SeqAutoRunPTOP 시퀀스 로직, PLC/IO/Laser/OCT/CellTracker 디바이스 통합, Rx.NET 이벤트 흐름을 분석하고 개선/확장 방안을 제시.
---
# PTOP Developer
## 핵심 역할
- **시퀀스 구현 분석** — SeqAutoRunPTOP, SeqAutoRunComponentWeld 등의 상태 머신, 타이밍, 에러 처리
- **디바이스 통합** — PLC, IO, Laser, OCT, CellTracker의 호출 흐름 및 동기화
- **Rx.NET 이벤트 체인** — 메시지 발행-구독 패턴, 스트림 처리, 에러 전파
- **구현 개선안 제시** — 코드 단순화, 버그 식별, 성능 최적화
## 작업 원칙
1. **SeqAutoRunPTOP.cs 심층 분석**
- 상태 머신 정의 (시작 → 준비 → 용접 → 완료 → 복구)
- 각 상태의 진입/종료 조건
- 타임아웃, 재시도, 폴백 로직
- 디바이스 호출 시점과 순서
2. **Device/ 폴더 전체 숙지**
- PLCController.Config.cs — PLC 주소 맵핑
- PLCController.Logic.cs — PLC 읽기/쓰기 로직
- PLCController.Address.cs — 신호 상수
- PAIX_PrismaticScanner.cs — IO 제어
3. **Rx.NET 메시지 흐름**
- System.Reactive 구독 패턴 추적
- 메시지 타입 (String/Double/Int/JSON/LBAD)
- 에러 처리 (OnError, Catch)
- 백프레셔(Backpressure) 관리
4. **Laser + OCT + CellTracker 통합**
- 각 디바이스의 초기화, 활성화, 비활성화 시점
- 순차 실행 vs 병렬 실행 여부
- 디바이스 간 신호 의존성
5. **Test 시퀀스 이해** (SeqTestRun, SeqStreamTest, SeqEventQTest)
- 각 테스트의 목적
- 메인 시퀀스와의 관계
- 디버깅/검증에 사용 가능성
## 입력/출력 프로토콜
**입력:**
- PTOP Lead의 TaskCreate: "시퀀스 구현 분석해줘", "PLC 통신 흐름 추적"
- PTOP Lead의 SendMessage: "이 부분이 명확하지 않은데 확인해줄 수 있나?"
**출력:**
1. **시퀀스 분석 보고서** (`_workspace/02_ptop_sequence_analysis.md`):
```markdown
# SeqAutoRunPTOP 분석
## 상태 머신
- State 정의
- 전이 조건
- 타임아웃 설정
## 디바이스 호출 순서
1. PLC.xxx() 호출
2. Laser.xxx() 호출
3. OCT 스캔
4. ...
## 에러 처리
- TimeoutException 처리
- PLC 오류 대응
- 복구 절차
## 개선 사항
- [우선순위] [설명]
```
2. **디바이스 통합 맵핑** (`_workspace/03_device_integration.md`):
```markdown
| 시퀀스 단계 | PLC 신호 | Laser | OCT | CellTracker | 타이밍 |
|-----------|---------|-------|-----|------------|--------|
| 시작 | Ready | - | - | - | T+0ms |
| 준비 | Setup | Standby | Init | Track | T+100ms |
| ... | ... | ... | ... | ... | ... |
```
3. **SendMessage to PTOP Lead**:
- 분석 완료 알림
- 주요 발견사항
- 불명확한 부분 목록
- 개선 우선순위
## 에러 핸들링
- 코드를 못 찾을 경우 → 정확한 파일 경로/라인 번호를 PTOP Lead에 요청
- 로직이 이해 안 될 경우 → "이 부분은 왜 이렇게 하는 걸까?" 질문을 문서에 명시
- 디바이스 호출 순서가 불명확할 경우 → 타이밍 다이어그램으로 시각화
## 팀 통신 프로토콜
**상급자:** PTOP Lead
**역할:**
- PTOP Lead의 지시를 받아 구현 분석 수행
- 분석 결과를 _workspace 파일로 저장
- SendMessage로 PTOP Lead에 진행상황 보고
- 불명확한 부분은 PTOP Lead에 질의
**기여:**
- 구현 단계 문제 조기 발견
- 코드 품질 정보 (복잡도, 버그 가능성)
- 성능/안정성 개선안
## 성공 기준
- [ ] SeqAutoRunPTOP의 상태 머신이 명확한 다이어그램으로 표현됨
- [ ] 모든 주요 디바이스 호출(PLC, Laser, OCT, CellTracker)이 타이밍과 함께 기록됨
- [ ] 각 시퀀스 단계의 예상 소요시간이 문서화됨
- [ ] 에러 케이스(TimeoutException, 디바이스 오류) 처리 방식이 명확함
- [ ] Rx.NET 메시지 흐름이 파이프라인으로 표현됨
- [ ] 발견된 구현 문제/개선 사항이 우선순위와 함께 나열됨
- [ ] 코드의 복잡한 부분(예: 동기화, 폴백)이 설명됨

105
.ubisam_agent/agents/ptop-lead.md Normal file
View File

@ -0,0 +1,105 @@
---
name: ptop-lead
description: ILSOS_PrismaticRD_PTOP 프로젝트의 아키텍처 리더. 최신 PTOP 시퀀스(SeqAutoRunPTOP.cs, 260605)를 중심으로 전체 구조 설계, 팀 조율, 공유 컴포넌트(PLC, IO, Laser, OCT, CellTracker) 통합을 담당.
---
# PTOP Lead (Architecture)
## 핵심 역할
- **PTOP 전체 아키텍처 설계 및 검토** — 3계층(UI → Machine Logic → Device) 구조 검증
- **팀 리더십** — 4명 팀원 작업 조율, 의존성 관리, 상충 해결
- **시퀀스-디바이스 통합** — SeqAutoRunPTOP과 PLC/IO/Laser 간 상호작용 검증
- **구현 진행 상황 추적** — 260605 이후 변경사항, 진행중인 기능 파악
## 작업 원칙
1. **ILSOS_PrismaticRD_PTOP 전체 파악**
- EquipDef.cs → EquipmentSetup.cs → Sequences/ → Device/ 통합 흐름
- 네임스페이스가 ILSOS_PrismaticScanner이지만 실제로 PTOP 모듈임을 이해
- SeqAutoRunPTOP.cs(260605)가 메인 시퀀스임을 중심으로
2. **시퀀스 인벤토리**
- SeqAutoRunPTOP (메인)
- SeqAutoRunPrismaticScanner (기존, 아직 존재)
- SeqAutoRunComponentWeld
- SeqTestRun, SeqStreamTest, SeqEventQTest
- 각 시퀀스의 활성 상태, 의존성 파악
3. **디바이스 스택**
- PLC (Mitsubishi) - 주요 제어
- IO (PAIX_PrismaticScanner.cs)
- Laser (AuroraLaser)
- OCT Scanner (AuroraOCT)
- CellTracker (AuroraCellTracker)
- 각 디바이스의 초기화, 통신, 에러 처리 흐름
4. **의존성 맵핑**
- WeldingCommon (공유 라이브러리)
- AuroraDevices (드라이버)
- System.Reactive (이벤트 기반)
5. **빌드 구성 이해**
- Debug/Release/Simulation/UserDefineUnit 중 PTOP에 적용되는 것
- 빌드 출력 (_out_prismatic_rd_ptop)
## 입력/출력 프로토콜
**입력:**
- 사용자: "PTOP 아키텍처 검토", "PTOP 시퀀스-디바이스 흐름 분석"
- 팀원들의 분석 결과 (SendMessage)
**출력:**
- **PTOP 아키텍처 검토 보고서** (`_workspace/01_ptop_architecture.md`):
- [ ] 3계층 아키텍처 다이어그램
- [ ] SeqAutoRunPTOP 메인 흐름도
- [ ] 디바이스 스택 매핑 (PLC, IO, Laser, OCT, CellTracker)
- [ ] 시퀀스 의존성 그래프
- [ ] Rx.NET 메시지 흐름
- [ ] 발견된 개선 사항 (우선순위)
- **팀 회의 진행 현황** (SendMessage로 각 팀원과 통신)
## 에러 핸들링
- 코드 구조가 불명확할 경우 → 해당 Specialist에게 심층 분석 요청
- 디바이스 간 상충 발견 → 양쪽 분석 결과를 병기하고 리뷰 회의 제안
- 시퀀스-디바이스 연결이 찾기 어려울 경우 → "이 신호는 어디서 올까?" 질문을 팀에 공개
## 팀 통신 프로토콜
**팀 구성원:**
- PTOP Sequence Specialist (시퀀스 분석)
- PTOP Device/PLC Expert (디바이스 분석)
- DevOps Engineer (빌드/배포 분석)
**발신 메시지:**
1. **TaskCreate** — 초기 작업 할당
```
[Task: Sequence Analysis]
SeqAutoRunPTOP.cs의 상태 머신, 타이밍, 디바이스 호출 분석
결과를 _workspace/02_ptop_sequences.md에 저장 후 SendMessage
```
2. **SendMessage** — 진행 중 질문, 상충 해결
```
[Q] SeqAutoRunPTOP에서 PLC.xxxx() 호출 시점이 명확하지 않습니다.
Device Expert의 분석과 함께 설명해주실 수 있나요?
```
3. **TaskUpdate** — 작업 진행상황 추적
**수신 대기:**
- 각 Specialist의 분석 결과 (SendMessage)
- 분석 완료 후 _workspace 파일 생성
## 성공 기준
- [ ] PTOP 전체 아키텍처가 명확하게 문서화됨 (다이어그램 포함)
- [ ] SeqAutoRunPTOP의 상태 머신이 이해됨
- [ ] 모든 주요 디바이스(PLC, IO, Laser, OCT, CellTracker)의 역할이 파악됨
- [ ] 각 시퀀스(Auto/Component/Test)의 목적과 의존성이 명확함
- [ ] Rx.NET 메시지 흐름이 예시화됨
- [ ] 발견된 개선 사항이 우선순위와 함께 나열됨
- [ ] 팀원 모두 PTOP 구조에 대해 같은 이해를 공유함

6
.ubisam_agent/settings.json Normal file
View File

@ -0,0 +1,6 @@
{
"enabledPlugins": {
"harness@harness-marketplace": true,
"serena@claude-plugins-official": true
}
}

210
.ubisam_agent/skills/analyze-ptop-architecture/SKILL.md Normal file
View File

@ -0,0 +1,210 @@
---
name: analyze-ptop-architecture
description: ILSOS_PrismaticRD_PTOP의 3계층 아키텍처(UI → Machine Logic → Device)를 분석하고 검증. EquipDef.cs, EquipmentSetup.cs, Sequences/, Device/ 폴더의 관계를 맵핑하고 Rx.NET 이벤트 흐름을 추적. 디바이스 스택(PLC, Laser, OCT, CellTracker) 통합 여부 검증. PTOP 아키텍처를 이해하거나 설계해야 할 때, "PTOP 아키텍처 분석", "PTOP 구조 검토", "PTOP 전체 흐름 파악" 요청 시 반드시 이 스킬을 사용.
---
# Analyze PTOP Architecture Skill
## 목표
ILSOS_PrismaticRD_PTOP의 **3계층 아키텍처 전체 그림**을 명확히 파악하고 문서화한다.
## 분석 단계
### 1단계: EquipDef.cs & EquipmentSetup.cs 분석
**EquipDef.cs에서 수집할 항목:**
- `CommonDeviceIds` 상속 항목 (MassFlowMeter 등)
- `CommonSequenceIds` 상속 항목 (SeqStreamTest, SeqEventQTest, SeqTestRun, SeqAutoRunComponentWeld, SeqAlarmMonitor, SeqStatusMonitor, SeqAutoRunPTOP)
- 커스텀 DeviceIds, SequenceIds, MotorIds
**EquipmentSetup.cs에서 수집할 항목:**
- `GetEquipmentName()` → 장비명 확인 ("ILSOS PrismaticRD_PTOP")
- `BuildMainStatusView()` → 표시되는 디바이스 (CellTracker, OCT)
- `OnSetAlarm()` 로직 → 알람 처리
- `OnStartUp()` 로직 → 초기화 순서
- SequenceBuilder 선언 → 실제 빌드되는 시퀀스
- `_SeqAutoRunPrismaticScanner_Builder`
- `_SeqAutoRunComponentWeld_Builder`
- `_SeqTestRun_Builder`
- `_SeqAlarmMonitor_Builder`
- `_SeqAutoRunPTOP_Builder` ← 메인 시퀀스 (260605)
**출력:** `_workspace/01a_equipdef_analysis.md`
### 2단계: Sequences/ 폴더 구조 분석
**주요 파일들:**
```
Sequences/
├── SeqAutoRunPTOP.cs ← 메인 (분석 우선순위 1)
├── SeqAutoRunPrismaticScanner.cs
├── SeqAutoRunComponentWeld.cs
├── SeqTestRun.cs
├── SeqStreamTest.cs
├── SeqEventQTest.cs
├── SequenceContextEx.cs ← 컨텍스트 정의
├── SequenceManager.cs ← 시퀀스 관리
├── Monitoring/
│ ├── SeqAlarmMonitor.cs
│ └── SeqStatusMonitor.cs
└── Manual/
└── SeqComponentTeachingRun.cs
```
**각 시퀀스 분석 항목:**
- 용도 (주 시퀀스? 테스트? 모니터링?)
- 상태 머신 정의 (시작, 대기, 실행, 완료, 에러)
- 타이밍 (예상 소요시간)
- 호출하는 디바이스 목록
- 의존성 (다른 시퀀스에 의존하는가?)
**특히 SeqAutoRunPTOP.cs:**
- 상태 다이어그램 작성
- 각 상태에서 호출되는 디바이스/API 추적
- 타임아웃/재시도 로직
**출력:** `_workspace/01b_sequences_analysis.md`
### 3단계: Device/ 폴더 분석
**파일 구조:**
```
Device/
├── PLC/
│ ├── PLCController.Config.cs ← PLC 주소 맵핑
│ ├── PLCController.Logic.cs ← 읽기/쓰기 로직
│ └── PLCController.Address.cs ← 신호 상수
└── IO/
└── PAIX_PrismaticScanner.cs ← IO 제어
```
**PLC 분석:**
- 사용되는 주소 범위 (예: M0~M100, D0~D500)
- 주요 신호 목록 (Ready, Setup, Error, etc.)
- 읽기 주기, 쓰기 주기
- 타임아웃 설정
**IO 분석:**
- 입력 신호 (센서, 스위치)
- 출력 신호 (제어 신호)
- 각 신호의 의미
**출력:** `_workspace/01c_device_analysis.md`
### 4단계: Rx.NET 이벤트 흐름 분석
**수집할 정보:**
- System.Reactive 사용 패턴 (Observable, Subject, etc.)
- 메시지 타입 (String/Double/Int/JSON/LBAD)
- 구독자 목록 (누가 어떤 메시지를 구독?)
- 백프레셔/에러 처리
**파이프라인 예시:**
```
[PLC Status] Observable
├─→ Filter(Ready == true)
├─→ Select(x => new LaserCommand())
└─→ Subscribe(Laser.Execute())
```
**출력:** `_workspace/01d_rxnet_analysis.md`
### 5단계: 외부 디바이스 통합 검증
**검증 대상:**
- PLC (Mitsubishi)
- Laser (AuroraLaser)
- OCT Scanner (AuroraOCT)
- CellTracker (AuroraCellTracker)
- IO (PAIX)
**각 디바이스마다:**
- 초기화 시점
- 활성화 조건
- 사용 방식 (동기/비동기)
- 에러 처리
- 정상 종료 절차
**출력:** `_workspace/01e_device_integration.md`
## 통합 산출물
### 최종 보고서: `_workspace/01_ptop_architecture.md`
```markdown
# ILSOS_PrismaticRD_PTOP 아키텍처 검토 보고서
## 1. 3계층 아키텍처
```
┌──────────────────────────────┐
│ WPF UI Layer │
│ (Views/, ViewModels/) │
└──────────────┬───────────────┘
↓
┌──────────────────────────────┐
│ Machine Logic Layer │
│ (EquipmentSetup, Sequences) │
└──────────────┬───────────────┘
↓
┌──────────────────────────────┐
│ Device Abstraction │
│ (AuroraDevices) │
└──────────────┬───────────────┘
↓
┌──────────────────────────────┐
│ Hardware Layer │
│ (PLC, Laser, OCT, etc.) │
└──────────────────────────────┘
```
## 2. 핵심 컴포넌트
### EquipDef & EquipmentSetup
- [EquipDef 매핑 표]
- [빌드되는 시퀀스 목록]
### Sequences
- [시퀀스 관계도]
- [SeqAutoRunPTOP 상태 머신]
### Device
- [PLC 신호 맵핑]
- [IO 신호 맵핑]
## 3. Rx.NET 이벤트 흐름
[파이프라인 다이어그램]
## 4. 발견 사항 & 개선 사항
| 우선순위 | 항목 | 현황 | 개선안 |
|---------|------|------|--------|
| P0 | | | |
| P1 | | | |
```
## 입력 조건
사용자가 다음과 같이 요청할 때:
- "PTOP 아키텍처 분석해줘"
- "PTOP 전체 구조 파악"
- "SeqAutoRunPTOP이 어떻게 동작하는지 분석"
- "PTOP에서 PLC, Laser, OCT가 어떻게 연결되어있는지"
- "PTOP 3계층 아키텍처 검증"
## 출력 결과
- 5개 상세 분석 문서 (`_workspace/01a~01e_*.md`)
- 통합 보고서 (`_workspace/01_ptop_architecture.md`)
- 다이어그램 (3계층, 상태 머신, 이벤트 흐름)
## 주의사항
1. **코드 읽기 능력이 중요** — C#, WPF, Rx.NET 이해 필수
2. **불명확한 부분은 기록** — "이 부분은 왜 이렇게?"라는 질문을 명시
3. **Namespace 혼동 주의** — ILSOS_PrismaticRD_PTOP의 코드가 ILSOS_PrismaticScanner 네임스페이스 사용
4. **260605 변경 이후 상태 파악** — SeqAutoRunPTOP이 최신 메인 시퀀스
5. **한글 주석 인코딩** — CODING_RULES.md 확인

209
.ubisam_agent/skills/analyze-ptop-implementation/SKILL.md Normal file
View File

@ -0,0 +1,209 @@
---
name: analyze-ptop-implementation
description: ILSOS_PrismaticRD_PTOP의 구현 상세 분석. SeqAutoRunPTOP 시퀀스 로직, PLC/Laser/OCT/CellTracker 디바이스 호출 흐름, Rx.NET 메시지 체인, 상태 전이, 타이밍, 에러 처리를 분석하고 구현 개선안 제시. "PTOP 시퀀스 로직 분석", "PLC 통신 흐름 추적", "디바이스 호출 순서", "타이밍 다이어그램" 요청 시 사용.
---
# Analyze PTOP Implementation Skill
## 목표
ILSOS_PrismaticRD_PTOP의 **구현 세부사항**을 분석하고 최적화 기회를 식별한다.
## 분석 영역
### 1단계: SeqAutoRunPTOP.cs 상태 머신 분석
**수집 대상:**
- 상태 정의 (enum/class로 표현된 상태들)
- 상태 진입 조건
- 상태 내 액션 (동작)
- 상태 종료 조건
- 상태 전이 경로
- 타임아웃 설정
- 재시도 로직
**산출 형식: 상태 다이어그램**
```
[시작]
↓ (T+0ms)
[초기화] → [준비] → [용접] → [완료] → [정리] → [대기]
↓ ↓ ↓ ↓ ↓
[에러 처리] ← ← ← ← ← ← ← ← ← ← ← ←
```
### 2단계: 디바이스 호출 시퀀스 추적
각 상태에서:
- 어떤 디바이스가 호출되는가?
- 호출 순서는? (순차 vs 병렬)
- 예상 소요시간?
- 다음 상태로의 전이 신호는 어디서 오는가?
**추적 대상:**
1. **PLC 호출**
- 읽기: PLC.ReadBool("M10"), PLC.ReadInt("D20"), etc.
- 쓰기: PLC.WriteBool("M5", true), PLC.WriteInt("D15", 100), etc.
- 대기: PLC 상태 폴링, 신호 기다리기
2. **Laser 제어**
- 활성화 (SetPower, SetFrequency, etc.)
- 대기
- 정상 종료
3. **OCT 스캔**
- 스캔 시작
- 데이터 수집
- 스캔 종료
4. **CellTracker**
- 셀 추적 시작
- 위치 업데이트
- 추적 종료
**산출 형식: 타이밍 다이어그램**
```
Time(ms) 0 100 200 300 400 500
State [INIT][PREP][WELD..................][DONE]
PLC ReadM10 ----WriteM5---- ReadM10
Laser ----SetPower-----------SetPower(0)
OCT --------Scan Start----Scan End
CellTrk ----Start----Update--Update--Stop
```
### 3단계: Rx.NET 메시지 체인 분석
**수집 대상:**
- Observable 소스 (어디서 데이터가 나오는가?)
- 변환 (Select, Map, Filter)
- 구독자 (누가 소비하는가?)
- 에러 처리 (OnError, Catch)
**예시:**
```csharp
// PLC 상태를 구독하여 Laser 제어
AuroraEnv.MessageQueue
.Where(msg => msg.Key == "PLC_Status")
.DistinctUntilChanged()
.Subscribe(msg =>
{
if (msg.Value == "Ready") {
Laser.SetPower(100);
}
});
```
**산출 형식: 메시지 파이프라인 맵**
### 4단계: 에러 처리 로직
**찾아야 할 패턴:**
- Try-Catch 블록
- TimeoutException 처리
- PLC 에러 응답 처리
- 디바이스 오류 복구
- 폴백 경로 (재시도, 초기화 재개, 강제 종료)
**각 에러에 대해:**
- 감지 방법
- 처리 방식
- 복구 가능 여부
- 사용자 개입 필요 여부
### 5단계: 성능/안정성 분석
**성능:**
- 각 상태의 예상 소요시간
- 전체 시퀀스 총 소요시간
- 병목 구간 (가장 오래 걸리는 부분)
- 최적화 기회 (병렬화 가능한가?)
**안정성:**
- 데드락 가능성 (두 디바이스가 서로 대기?)
- 타이밍 이슈 (신호 도착 순서 의존?)
- 리소스 누수 (구독 취소 안 됨?)
- 상태 불일치 (PLC와 소프트웨어 상태 차이?)
## 통합 산출물
### 최종 보고서: `_workspace/02_ptop_implementation.md`
```markdown
# PTOP 구현 분석 보고서
## 1. 상태 머신
[다이어그램]
## 2. 디바이스 호출 시퀀스
### 시작 → 준비 전이
- T+0ms: PLC ReadBool("M10", Ready) 확인
- T+50ms: Laser SetPower(100) 호출
- T+100ms: OCT Scan Start
- 조건: 모든 디바이스 Ready ⇒ 다음 상태로 전이
[세부 타이밍 테이블]
## 3. Rx.NET 메시지 흐름
```
PLC Status Observable
└─ Filter(Ready)
└─ Select(→ LaserCommand)
└─ Subscribe(Laser.Execute)
```
## 4. 에러 처리
| 에러 유형 | 감지 방법 | 처리 방식 | 복구 가능 |
|---------|---------|---------|---------|
| PLC Timeout | ReadBool() 예외 | 재시도 3회 | Yes |
| Laser Error | Laser.Status != OK | 전원 차단 후 재시작 | Yes |
| ... | ... | ... | ... |
## 5. 성능 프로파일
| 구간 | 소요시간 | 최적화 기회 |
|------|---------|----------|
| 준비 단계 | 200ms | 병렬화 불가 |
| 용접 단계 | 1500ms | OCT 스캔 시간 단축? |
| ... | ... | ... |
## 6. 발견 사항
### P0 (심각)
- [내용]
### P1 (중요)
- [내용]
### P2 (개선)
- [내용]
```
## 입력 조건
사용자가 다음 요청 시:
- "PTOP 시퀀스 로직 상세 분석"
- "SeqAutoRunPTOP이 PLC/Laser/OCT을 어떻게 제어하는가"
- "PTOP 타이밍 분석"
- "PTOP에서 에러가 발생하면 어떻게 처리되나"
- "PTOP의 성능 병목은"
## 출력 결과
- 상태 머신 다이어그램
- 타이밍 다이어그램 (시간축)
- Rx.NET 메시지 흐름도
- 에러 처리 매트릭스
- 성능 프로파일
- 최종 분석 보고서
## 주의사항
1. **코드 라인 번호 기록** — "Line 245의 try-catch" 형식으로 정확한 위치 기록
2. **데이터 흐름 추적** — 변수, 반환값을 따라가며 이해
3. **시간 측정** — Thread.Sleep() / Task.Delay() / TimeSpan 찾기
4. **예외 처리** — Exception 타입별로 분류
5. **불명확한 부분 기록** — 추측 금지, 명시적으로 "불명확함" 표시

248
.ubisam_agent/skills/optimize-ptop-build/SKILL.md Normal file
View File

@ -0,0 +1,248 @@
---
name: optimize-ptop-build
description: ILSOS_PrismaticRD_PTOP의 빌드 최적화 및 CI/CD 자동화. 멀티 구성 빌드(Debug/Release/Simulation/UserDefineUnit) 분석, 의존성 최적화, 빌드 시간 단축, CI/CD 파이프라인 설계. "빌드 최적화", "PTOP 빌드 성능", "CI/CD 자동화 설계", "배포 파이프라인" 요청 시 사용.
---
# Optimize PTOP Build Skill
## 목표
ILSOS_PrismaticRD_PTOP의 **빌드 성능 및 자동화**를 최적화한다.
## 분석 영역
### 1단계: 현재 빌드 상태 분석
**수집 대상:**
- 솔루션 내 프로젝트 목록 (ILSOS_All.sln)
- PTOP이 참조하는 프로젝트
- 각 프로젝트의 빌드 시간 측정
**측정 방법:**
```powershell
# Visual Studio 빌드 시간 측정
msbuild ILSOS_All.sln /p:Configuration=Release /p:Platform=x64 /d:MSBUILDENABLEALLPROJECTSBUILDFASTPATH=true
# 또는 개별 구성별
msbuild ILSOS_All.sln /p:Configuration=Simulation /p:Platform=x64
```
**수집 항목:**
| 구성 | 총 소요시간 | 병목 프로젝트 (상위 3) | 캐시 효율 |
|------|-----------|------------------|---------|
| Debug|x64 | ? | ? | ? |
| Release|x64 | ? | ? | ? |
| Simulation|x64 | ? | ? | ? |
| UserDefineUnit|x64 | ? | ? | ? |
### 2단계: 의존성 분석
**PTOP의 최소 필수 의존성 파악:**
```
ILSOS_PrismaticRD_PTOP
├── WeldingCommon (필수)
├── WeldingComponents (필수)
│ ├── WeldingCommon.dll
│ ├── LASAGUI (용접 GUI)
│ └── ...
├── AuroraDevices (선택적)
│ ├── AuroraLaser (필수 - Laser 제어)
│ ├── AuroraOCT (필수 - OCT 스캔)
│ ├── AuroraPLC (필수 - PLC 통신)
│ ├── AuroraIO (필수 - IO 제어)
│ ├── AuroraCellTracker (필수 - 셀 추적)
│ ├── AuroraLBAD (?)
│ └── ... (기타 22개 중 필요 없는 것?)
├── AuroraComponents (필수)
├── AuroraVision (필요하나?)
└── NuGet 패키지 (Reactive, Json.NET, etc.)
```
**분석:**
- 각 AuroraDevices 프로젝트의 실제 사용 여부
- 제거 가능한 의존성
- 조건부 컴파일 가능성 (#if DEBUG 등)
**산출물:** `_workspace/04a_dependency_analysis.csv`
### 3단계: 빌드 구성별 최적화
#### Debug|x64 최적화
- 기호 생성 필요 (유지)
- 최적화 비활성화 (유지)
- 증분 빌드 활용
#### Release|x64 최적화
```xml
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
<Optimize>true</Optimize> <!-- 최적화 활성화 -->
<DebugType>embedded</DebugType> <!-- 기호 축소 -->
<TieredCompilation>true</TieredCompilation> <!-- .NET 4.8.1 지원하나? -->
<PublishTrimmed>true</PublishTrimmed> <!-- 불필요 어셈블리 제거 -->
</PropertyGroup>
```
#### Simulation|x64 최적화
```csharp
#if SIMULATION
// 하드웨어 통신 불필요 - 모의 구현 사용
public class MockPLC : IPLC { ... }
#endif
```
#### UserDefineUnit|x64 최적화
- 용도 파악 필요 (단위 테스트? 커스텀 하드웨어?)
- 필요한 기능만 포함
### 4단계: CI/CD 파이프라인 설계
**목표:**
- 자동 빌드 (commit, PR)
- 자동 테스트 (Simulation 구성)
- 자동 배포 (수동 승인)
**추천 플랫폼:**
- GitHub Actions (GitHub 저장소 사용 중 가정)
- Azure Pipelines (Microsoft 클라우드)
- Jenkins (온프레미스)
**파이프라인 구조:**
```yaml
# .github/workflows/ptop-build.yml
name: PTOP Build & Deploy
on:
push:
branches: [main, develop]
paths: ['Machines/ILSOS_PrismaticRD_PTOP/**']
pull_request:
branches: [main]
jobs:
build:
runs-on: windows-latest
strategy:
matrix:
config: [Debug, Release, Simulation]
steps:
- uses: actions/checkout@v3
- name: Setup .NET Framework
uses: microsoft/setup-msbuild@v1
- name: Restore NuGet
run: nuget restore ILSOS_All.sln
- name: Build (${{ matrix.config }})
run: msbuild ILSOS_All.sln /p:Configuration=${{ matrix.config }} /p:Platform=x64
- name: Run Tests (Simulation only)
if: matrix.config == 'Simulation'
run: # 테스트 실행 명령
- name: Upload Artifacts
uses: actions/upload-artifact@v3
with:
name: ptop-${{ matrix.config }}
path: Machines/_out_prismatic_rd_ptop/x64-${{ matrix.config }}/
deploy:
needs: build
runs-on: windows-latest
if: github.ref == 'refs/heads/main'
environment: production # 수동 승인 필수
steps:
- name: Download Release Artifact
- name: Create Release Package
run: # 패키징 스크립트
- name: Deploy to Server
run: # 배포 스크립트
```
### 5단계: 배포 패키징
**산출물:**
- 실행 가능 파일 (Aurora.exe)
- 필수 DLL (AuroraDevices, WeldingComponents, etc.)
- 설정 파일 (app.config)
- 리소스 파일 (이미지, 데이터)
- 배포 설명서
**패키징 형식:**
- ZIP 아카이브 (간단)
- NSIS 설치 프로그램 (사용자 친화적)
- Chocolatey 패키지 (자동 업데이트)
## 통합 산출물
### 최종 보고서: `_workspace/04_ptop_build_optimization.md`
```markdown
# PTOP 빌드 최적화 보고서
## 1. 현재 빌드 성능
| 구성 | 시간 | 병목 | 개선 가능성 |
|------|------|------|----------|
| Debug|x64 | 45s | ? | 개선 중심 |
| Release|x64 | 60s | ? | 최적화 중심 |
| Simulation|x64 | 50s | ? | 테스트 환경 |
| UserDefineUnit|x64 | 55s | ? | 커스텀 |
## 2. 의존성 최적화
### 필수 의존성
- AuroraLaser, AuroraOCT, AuroraPLC, etc.
### 제거 가능 의존성
- ...
## 3. 빌드 구성별 최적화 전략
### Debug
- 현황: [상태]
- 개선안: [목표]
- 예상 효과: [시간 단축]
### Release
- ...
### Simulation
- ...
## 4. CI/CD 파이프라인
[YAML 파일 포함]
## 5. 배포 패키징
[패키징 스크립트]
## 6. 예상 효과
- 빌드 시간: XX% 단축
- 배포 시간: XX% 단축
- 자동화: 수동 작업 제거
```
## 입력 조건
사용자 요청 시:
- "PTOP 빌드 최적화"
- "빌드 시간 단축"
- "CI/CD 파이프라인 설계"
- "배포 자동화"
- "Release 빌드 성능"
## 출력 결과
- 빌드 성능 분석 보고서
- 의존성 맵핑 CSV
- CI/CD 파이프라인 (YAML/JSON)
- 빌드 최적화 설정 (PropertyGroup)
- 배포 패키징 스크립트
- 최종 보고서
## 주의사항
1. **.NET Framework 4.8.1 호환성** — 최신 .NET 기능 사용 불가
2. **Visual Studio 2022 기준** — MSBuild 경로 확인
3. **Windows 플랫폼 전용** — x64 아키텍처 명시
4. **빌드 머신 사양** — CI 환경의 OS/RAM 확인
5. **라이선스 확인** — NuGet 패키지, 외부 도구의 라이선스

286
.ubisam_agent/skills/orchestrate-ptop-harness/SKILL.md Normal file
View File

@ -0,0 +1,286 @@
---
name: orchestrate-ptop-harness
description: ILSOS_PrismaticRD_PTOP 개발 팀의 오케스트레이터. 3명 팀원(PTOP Lead, PTOP Developer, Build/DevOps Engineer)의 작업을 조율하고 아키텍처 분석, 구현 분석, 빌드 최적화를 통합 진행. "PTOP 프로젝트 종합 분석", "PTOP 전체 점검", "PTOP 하네스 시작", "PTOP 팀 조율" 요청 시 사용.
---
# Orchestrate PTOP Harness Skill
## 목표
ILSOS_PrismaticRD_PTOP의 **3계층 아키텍처**, **구현 상세**, **빌드 최적화**를 **병렬 분석**하여 팀원들이 조율하며 통합 보고서를 완성한다.
## 실행 모드
**에이전트 팀** (팀 조율 활성화)
```
[오케스트레이터]
├─ TeamCreate(team=[PTOP Lead, PTOP Developer, Build/DevOps Engineer])
├─ Phase 1: 초기 컨텍스트 확인
├─ Phase 2: 병렬 분석 작업 할당 (TaskCreate + 팀원 간 SendMessage)
├─ Phase 3: 결과 수집 및 통합
├─ Phase 4: 최종 검증
└─ Phase 5: 팀 해제
```
## 워크플로우
### Phase 1: 초기 컨텍스트 확인 (5분)
**수행 항목:**
1. `_workspace/` 디렉토리 존재 여부 확인
- 존재 → 기존 분석 파일 로드, 부분 재실행 검토
- 미존재 → 새 작업 시작
2. 기존 분석이 있으면:
- 이전 PTOP Lead의 보고서 검토
- PTOP Developer의 발견사항 검토
- Build Engineer의 개선안 검토
- → 파일을 `_workspace_prev/`로 이동 후 신규 분석 진행
**산출:**
- Phase 1 진행 상황 (TaskCreate 할당)
### Phase 2: 병렬 분석 작업 할당 (15~20분)
**TaskCreate 3개 발행:**
#### Task 2-1: PTOP Lead — 아키텍처 분석
```
Role: PTOP Lead
Task: analyze-ptop-architecture 스킬 실행
Input:
- ILSOS_PrismaticRD_PTOP 소스 전체
- CLAUDE.md 프로젝트 컨텍스트
Output:
- _workspace/01a_equipdef_analysis.md
- _workspace/01b_sequences_analysis.md
- _workspace/01c_device_analysis.md
- _workspace/01d_rxnet_analysis.md
- _workspace/01e_device_integration.md
- _workspace/01_ptop_architecture.md (통합)
Deadline: 20분
Status: in_progress
```
#### Task 2-2: PTOP Developer — 구현 분석
```
Role: PTOP Developer
Task: analyze-ptop-implementation 스킬 실행
Input:
- PTOP Lead의 01_ptop_architecture.md (참고)
- SeqAutoRunPTOP.cs, Device/* 소스
Output:
- _workspace/02_ptop_implementation.md (상태 머신, 타이밍, 에러 처리 포함)
Dependencies: Task 2-1의 아키텍처 정의 완료 후 진행
Deadline: 20분
Status: blocked (대기)
```
#### Task 2-3: Build/DevOps Engineer — 빌드 최적화
```
Role: Build/DevOps Engineer
Task: optimize-ptop-build 스킬 실행
Input:
- ILSOS_All.sln 파일
- 현재 빌드 환경 정보
Output:
- _workspace/04a_dependency_analysis.csv
- _workspace/04_ptop_build_optimization.md (CI/CD 파이프라인 포함)
Status: in_progress (독립적)
Deadline: 15분
```
**병렬 실행 전략:**
- Task 2-1과 2-3은 독립적 → 동시 진행
- Task 2-2는 Task 2-1 결과 참고 필요 → 순차
**팀 통신:**
```
[오케스트레이터 → PTOP Lead]
"아키텍처 분석 시작. 20분 안에 01_ptop_architecture.md 완성 부탁."
[오케스트레이터 → PTOP Developer]
"PTOP Lead의 아키텍처 분석 대기 중. 시작 신호 받으면 구현 분석 시작할 것."
[오케스트레이터 → Build/DevOps Engineer]
"빌드 최적화 분석 시작. 15분 안에 04_ptop_build_optimization.md 완성 부탁."
```
### Phase 3: 중간 체크포인트 (10분)
**T+10분 타이밍:**
```
[오케스트레이터]
- PTOP Lead의 01_ptop_architecture.md 완성 확인
- Build/DevOps Engineer의 진행상황 확인
[PTOP Developer에게 GO신호 발행]
"PTOP Lead의 아키텍처 분석 완료. 이제 구현 분석 시작해주세요."
```
**SendMessage 패턴:**
```
[오케스트레이터 → PTOP Lead, PTOP Developer]
"두 분석의 연계 포인트를 확인해주세요.
- 아키텍처에서 정의한 3계층이 구현에 제대로 반영되었나?
- 의도하지 않은 구조가 있나?"
```
### Phase 4: 결과 수집 (5분)
**수행 항목:**
1. 3개 분석 결과 파일 모두 완성 확인
2. 각 팀원의 발견사항 요약 요청 (SendMessage)
```
[오케스트레이터 → 각 팀원]
"분석 완료되셨나요? 가장 중요한 발견 3개를 나열해주세요."
PTOP Lead의 응답:
1. SeqAutoRunPTOP이 메인 시퀀스이고 260605에 추가됨
2. PLC, Laser, OCT, CellTracker 모두 필수 디바이스
3. Rx.NET 메시지 흐름이 복잡 - 개선 필요
PTOP Developer의 응답:
1. 상태 머신이 명확하지 않은 부분 발견 (XXX)
2. PLC 호출 순서가 타이밍 크리티컬
3. OCT 스캔 시간 최적화 기회
Build/DevOps Engineer의 응답:
1. Release 빌드가 Debug보다 20% 느림
2. AuroraDevices 중 불필요한 프로젝트 5개 발견
3. CI/CD 파이프라인 설계 완료
```
### Phase 5: 통합 보고서 생성 (10분)
**오케스트레이터가 종합:**
`_workspace/00_PTOP_HARNESS_SUMMARY.md` 생성
```markdown
# ILSOS_PrismaticRD_PTOP 하네스 분석 — 종합 보고서
**분석 일시:** [날짜]
**팀원:** PTOP Lead, PTOP Developer, Build/DevOps Engineer
**총 소요시간:** ~50분
---
## Executive Summary
ILSOS_PrismaticRD_PTOP은 [간단 설명]
### 주요 발견
#### 아키텍처 (PTOP Lead)
- 3계층 구조 검증 완료
- 핵심 컴포넌트: [리스트]
- 개선 우선순위: [P0, P1, P2]
#### 구현 (PTOP Developer)
- 상태 머신 분석 완료
- 성능 병목: [리스트]
- 안정성 이슈: [리스트]
#### 빌드 (Build/DevOps Engineer)
- 빌드 성능: [현황]
- 의존성 최적화: [개선안]
- CI/CD: [설계 완료]
---
## 상세 분석
### 1. 아키텍처
[01_ptop_architecture.md 요약]
### 2. 구현
[02_ptop_implementation.md 요약]
### 3. 빌드 & DevOps
[04_ptop_build_optimization.md 요약]
---
## 종합 권장사항
| 우선순위 | 항목 | 담당 | 예상 공수 |
|---------|------|------|---------|
| P0 | [긴급] | PTOP Developer | ? |
| P1 | [중요] | PTOP Lead | ? |
| P2 | [개선] | Build/DevOps Engineer | ? |
---
## 다음 단계
1. 이 보고서 검토 (팀 + 사용자)
2. P0 항목 즉시 대응
3. P1 항목 일정 수립
4. P2 항목 백로그 등록
---
## 부록
- [분석 파일 목록]
- [팀 통신 기록]
- [시간 로그]
```
### Phase 6: 팀 정리 및 후속 계획
```
[오케스트레이터]
✓ 팀 해제 (TeamDelete)
✓ 최종 보고서 제출
→ 사용자에게 결과 요약 제시
[사용자에게 제시]
"PTOP 하네스 분석 완료. 주요 발견:
1. 아키텍처: 3계층 구조 검증 완료 (문서: 01_ptop_architecture.md)
2. 구현: 상태 머신 분석, 성능 병목 식별 (문서: 02_ptop_implementation.md)
3. 빌드: 최적화 기회 발견, CI/CD 설계 완료 (문서: 04_ptop_build_optimization.md)
다음 단계: 보고서 검토 → P0 항목 대응"
```
## 데이터 전달 프로토콜
| 전달 객체 | 방식 | 용도 |
|----------|------|------|
| 팀원 간 작업 결과 | 파일 (_workspace/) | 아키텍처 → 구현 분석 의존성 |
| 팀원 간 실시간 소통 | SendMessage | 질문, 상충 해결, 진행상황 |
| 최종 산출물 | 통합 보고서 + 세부 파일 | 사용자 제시 |
## 에러 핸들링
| 상황 | 처리 방식 |
|------|---------|
| 팀원 분석 지연 | 진행상황 확인, 추가 시간 할당 |
| 팀원 간 의견 상충 | SendMessage로 토론, 양쪽 견해 모두 기록 |
| 코드 이해 불가 | 해당 부분을 "불명확" 표시하고 진행 |
| 분석 결과 불완전 | 세부 파일에 "TODO" 표시, 최종 보고서에 명시 |
## 성공 기준
- [ ] 5개 세부 분석 문서 완성 (01a~01e, 02, 04a, 04)
- [ ] 3개 팀원 모두 할당된 작업 완료
- [ ] 통합 보고서 (00_PTOP_HARNESS_SUMMARY.md) 생성
- [ ] 주요 발견사항 3개 이상 도출
- [ ] 권장사항(P0/P1/P2)이 명확히 기술됨
- [ ] 모든 분석이 코드 레퍼런스와 함께 기술됨
- [ ] 팀원 간 의견 상충 없이 완료되거나, 상충이 있으면 명시적으로 기록됨
## 후속 작업
이 하네스는 초기 분석이며, 이후:
- P0 항목 대응 후 재검토
- P1 항목 진행 중 코드 리뷰 (별도 하네스)
- P2 항목 백로그 관리
**재실행 트리거:**
- 사용자가 "PTOP 재분석", "PTOP 상태 업데이트" 요청 시
- 주요 코드 변경 후 영향도 분석 필요 시

139
CLAUDE.md
View File

@ -1,137 +1,24 @@
# ILSOS 프로젝트 — Claude 초기 컨텍스트
## 프로젝트 개요
## 프로젝트 문서
**OC5 PilotLine RectangleTypeWelder** — 각형 배터리 용접 자동화 시스템
@import ./docs/project-overview.md — 목표, 플랫폼, 빌드 구성, 머신 모듈 소개
- **플랫폼**: Windows 10, .NET Framework 4.8.1, Visual Studio 2022
- **UI 프레임워크**: WPF (Aurora 프레임워크 기반)
- **솔루션 파일**: `ILSOS_All.sln`
- **빌드 구성**: Debug|x64 / Release|x64 / Simulation|x64 / UserDefineUnit|x64
@import ./docs/solution-structure.md — 전체 솔루션 구조 및 주요 레이어
@import ./docs/ptop-architecture.md — PTOP 폴더 구조, ID 정의, 3계층 아키텍처
@import ./docs/aurora-devices.md — 22개 하드웨어 디바이스 드라이버 목록
@import ./docs/build-output.md — 머신별 빌드 출력 경로
@import ./docs/harness-ptop.md — PTOP 분석 팀 구성 및 호출 방법
---
## 머신 모듈 (Machines/)
## 협업 규칙
### ILSOS_PrismaticGun
- **레이저는 고정**, 스테이지(Stage A / Stage B)가 이동하면서 용접
- 레이저 하나를 **Stage A ↔ Stage B 간 스위칭**하여 용접 진행
- 모션 제어: **ACS (X/Y축)** + **Ajin (Z축)** 혼합 구성
- PLC: Mitsubishi PLC 통신
- 시퀀스 구조: `Sequences/SubSequence/StageA/` + `Sequences/SubSequence/StageB/` 이원화
### ILSOS_PrismaticScanner
- **레이저 스캐너**를 통해 용접 진행
- 레이저 인터페이스 모듈이 PrismaticGun과 다름 (`AuroraLaserScanner`)
- 단일 스테이지 구조
### ILSOS_PrismaticCleanLaser
- **CleanLaser** 인터페이스 모듈 사용 (PrismaticScanner과도 다름)
- 파일 구조는 PrismaticScanner와 유사하나 레이저 디바이스 인터페이스가 상이함
- 단일 스테이지 구조
---
## 전체 솔루션 구조
```
ILSOS_All.sln
├── Machines/
│ ├── ILSOS_PrismaticGun/ ← 레이저 고정, 스테이지 이동 용접 (Stage A/B)
│ ├── ILSOS_PrismaticScanner/ ← 스캐너 레이저 용접
│ └── ILSOS_PrismaticCleanLaser/ ← 클린 레이저 용접
├── AuroraDevices/ ← 하드웨어 디바이스 드라이버 (22개 프로젝트)
├── AuroraComponents/ ← WPF UI 공통 컴포넌트
├── AuroraVision/ ← 비전 시스템 (MIL 기반)
├── WeldingComponents/ ← 용접 공통 기능 (WeldingCommon, LASAGUI)
└── External/ ← Aurora 프레임워크 바이너리
```
---
## 주요 AuroraDevices 목록
| 프로젝트 | 역할 |
|---------|------|
| AuroraACS | ACS SPiiPlus 모션 컨트롤러 |
| AuroraLaser | 레이저 제어 (Gun 타입) |
| AuroraLaserScanner | 레이저 스캐너 제어 |
| AuroraPLC | PLC 통신 (Mitsubishi Melsec) |
| AuroraIO | 디지털 I/O |
| AuroraHeightSensor | 높이 센서 (Keyence) |
| AuroraCellTracker | 팰릿/셀 추적 시스템 |
| AuroraChiller | 냉각 장치 제어 |
| AuroraOCT | OCT 스캐너 (Trumpf) |
| AuroraMotionBoard | 모션 보드 (Ajin) |
| AuroraDeviceCommon | 디바이스 공통 기본 클래스 |
---
## ILSOS_PrismaticGun 핵심 구조
### 폴더 구조
```
ILSOS_PrismaticGun/
├── EquipDef.cs ← ID 상수 정의 (Device/Motor/Sequence/Recipe)
├── EquipmentSetup.cs ← 통합 제어 (초기화, 이벤트 구독, 시퀀스 시작)
├── Alarm/ ← 알람 코드 및 매니저
├── Device/
│ ├── ACS/ ← ACS 모션 제어 (X/Y축)
│ └── PLC/ ← PLC 통신 로직
├── Models/ ← 장비 특화 모델
├── Process/ ← ProcessManager, CellInfo, WeldingData
├── Recipes/ ← MainRecipe, RMSHandler
├── Sequences/
│ ├── Monitoring/ ← 알람/상태 모니터링 시퀀스
│ ├── SeqAutoRunPrismaticGunStageA/B.cs
│ └── SubSequence/
│ ├── StageA/ ← Load, Weld, Unload, HeightMeas (Stage A)
│ └── StageB/ ← Load, Weld, Unload, HeightMeas (Stage B)
├── settings/ ← 세팅 정의 클래스
├── Tools/ ← 공통 유틸리티
└── Views/ ← WPF View/ViewModel
```
### 주요 ID (EquipDef.cs)
- **DeviceIds**: ACS, MassFlowMeterStageA/B, HeightSensor, AJIN
- **MotorIds**: ALineX/Y/Z, BLineX/Y/Z
- **RecipeIds**: StageAMainRecipe, StageBMainRecipe
- **SequenceIds**: SeqLoad/Weld/Unload/HeightMeas × StageA/B
---
## 아키텍처 패턴
```
WPF UI Layer (Views/ + ViewModels)
↓
Machine Logic Layer (EquipmentSetup + Sequences + Process)
↓
Device Abstraction (AuroraDevices — 디바이스별 독립 모듈)
↓
Hardware Layer (ACS.SPiiPlusNET, Melsec, Serial/USB)
```
- **이벤트 기반**: `System.Reactive` (Rx.NET)
- **글로벌 환경**: `AuroraEnv` (의존성 주입 패턴)
- **메시지 큐**: String / Double / Int / JSON / LBAD 타입
---
## 빌드 출력 경로
| 머신 | 출력 경로 |
|------|---------|
| ILSOS_PrismaticGun | `_out_prismatic_gun/` |
| ILSOS_PrismaticScanner | `_out_prismatic_scanner/` |
| ILSOS_PrismaticCleanLaser | `_out_prismatic_cleanlaser/` |
---
## 코딩 규칙
파일 수정 시 **반드시 `docs/CODING_RULES.md`를 먼저 확인**할 것.
특히 한글이 포함된 파일 생성/수정 시 인코딩 규칙을 따라야 함.
@import ./rules.md
---

12
docs/CODING_RULES.md
View File

@ -77,16 +77,6 @@ file 파일경로.cs
## 4. 시퀀스 작성 규칙
### Stage A / Stage B 이원 구조 유지
- PrismaticGun에서 StageA와 StageB 시퀀스는 **항상 대칭적으로** 작성한다.
- StageA에 기능을 추가하면 StageB에도 동일하게 추가한다.
### 시퀀스 파일 위치
```
Sequences/SubSequence/StageA/SeqXxx.cs ← Stage A 전용
Sequences/SubSequence/StageB/SeqXxx.cs ← Stage B 전용 (StageA와 대칭)
```
### ID 등록
- 새 시퀀스/디바이스/레시피/뷰 추가 시 **반드시** `EquipDef.cs`의 해당 ID 클래스에 상수를 먼저 등록한다.
@ -120,6 +110,6 @@ Sequences/SubSequence/StageB/SeqXxx.cs ← Stage B 전용 (StageA와 대칭)
| 작업 | 규칙 |
|------|------|
| 새 C# 파일 생성 | UTF-8 BOM + CRLF 적용 필수 |
| 새 시퀀스 추가 | EquipDef.cs ID 등록 → 파일 생성 → StageA/B 대칭 |
| 새 시퀀스 추가 | EquipDef.cs ID 등록 → 파일 생성 |
| 새 디바이스 추가 | EquipDef.cs → EquipmentSetup.cs → BuildMainStatusView |
| 한글 포함 수정 | 수정 후 BOM/CRLF 검증 |

22
docs/aurora-devices.md Normal file
View File

@ -0,0 +1,22 @@
# AuroraDevices 모듈 목록
AuroraDevices는 하드웨어 디바이스 제어를 담당하는 22개 프로젝트 모음입니다.
| 프로젝트 | 역할 | 비고 |
|---------|------|------|
| AuroraDeviceCommon | 디바이스 공통 기본 클래스 | 모든 디바이스 상속 |
| AuroraACS | ACS SPiiPlus 모션 컨트롤러 | X/Y축 모션 제어 |
| AuroraMotionBoard | Ajin 모션 보드 | Z축 모션 제어 |
| AuroraLaser | 레이저 제어 (Gun 타입) | 고정 레이저 |
| AuroraLaserScanner | 레이저 스캐너 제어 | 동적 스캐닝 |
| AuroraPLC | Mitsubishi Melsec PLC 통신 | 외부 신호 제어 |
| AuroraIO | 디지털 I/O | 입출력 신호 |
| AuroraHeightSensor | Keyence 높이 센서 | 높이 측정 |
| AuroraCellTracker | 팰릿/셀 추적 시스템 | 셀 인식 및 위치 추적 |
| AuroraChiller | 냉각 장치 | 온도 제어 |
| AuroraOCT | Trumpf OCT 스캐너 | 옵티컬 측정 |
**설계 원칙:**
- 각 디바이스는 독립적인 제어 로직 구현
- 통합 제어는 머신 모듈의 EquipmentSetup에서 담당
- 의존성 주입(DI) 패턴으로 느슨한 결합 유지

22
docs/build-output.md Normal file
View File

@ -0,0 +1,22 @@
# 빌드 출력 경로
## 머신별 빌드 디렉토리
| 머신 모듈 | 출력 경로 | 상태 |
|---------|---------|------|
| ILSOS_PrismaticPTOP | `_out_prismatic_ptop/` | 활성 |
| ILSOS_PrismaticScanner | `_out_prismatic_scanner/` | 참고 |
| ILSOS_PrismaticGun | `_out_prismatic_gun/` | 미사용 |
| ILSOS_PrismaticCleanLaser | `_out_prismatic_cleanlaser/` | 미사용 |
## 빌드 구성별 출력
각 빌드 구성(Debug, Release, Simulation, UserDefineUnit)은 플랫폼(x64)별로 독립적인 출력 디렉토리 생성.
예: `_out_prismatic_ptop/Debug/x64/`, `_out_prismatic_ptop/Release/x64/`
## 주의사항
- 빌드 출력 디렉토리는 `.gitignore`에 포함
- 빌드 전 이전 출력물이 있으면 자동 정리
- 각 머신 모듈은 독립적으로 빌드 가능

42
docs/harness-ptop.md Normal file
View File

@ -0,0 +1,42 @@
# 하네스: ILSOS_PrismaticRD_PTOP 분석 팀
## 목표
ILSOS_PrismaticRD_PTOP(PtoP)의 3계층 아키텍처, 구현 상세, 빌드 최적화를 종합 분석하고 개선안 제시
## 팀 구성
- **PTOP Lead**: 아키텍처 리더
- **PTOP Developer**: 구현 전문가
- **Build/DevOps Engineer**: 빌드 최적화 담당
## 호출 방법
다음 요청 시 `/orchestrate-ptop-harness` 스킬 사용:
- "PTOP 프로젝트 전체 분석"
- "PTOP 아키텍처와 구현 분석"
- "PTOP 상태 점검"
- "PTOP 빌드 최적화"
- "PTOP 팀 조율"
## 구성 요소
**Agents:**
- `.ubisam_agent/agents/ptop-lead.md`
- `.ubisam_agent/agents/ptop-developer.md`
- `.ubisam_agent/agents/build-devops-engineer.md`
**Skills:**
- `.ubisam_agent/skills/analyze-ptop-architecture/SKILL.md`
- `.ubisam_agent/skills/analyze-ptop-implementation/SKILL.md`
- `.ubisam_agent/skills/optimize-ptop-build/SKILL.md`
- `.ubisam_agent/skills/orchestrate-ptop-harness/SKILL.md`
**Workspace:**
- `_workspace/0X_*.md` (분석 결과 저장)
## 변경 이력
| 날짜 | 변경 내용 | 대상 | 사유 |
|------|----------|------|------|
| 2026-06-16 | 초기 구성 | agents/, skills/ | PTOP이 핵심 활성 모듈 |

30
docs/project-overview.md Normal file
View File

@ -0,0 +1,30 @@
# 프로젝트 개요
## ILSOS - OC5 PilotLine RectangleTypeWelder
**목표:** 각형 배터리 용접 자동화 시스템
**플랫폼 및 기술:**
- OS: Windows 10 / Windows 11
- 프레임워크: .NET Framework 4.8.1
- IDE: Visual Studio 2022
- UI 프레임워크: WPF (Aurora 프레임워크 기반)
- 솔루션 파일: `ILSOS_All.sln`
**빌드 구성:**
- Debug | x64
- Release | x64
- Simulation | x64
- UserDefineUnit | x64
**주요 머신 모듈:**
- **ILSOS_PrismaticPTOP**: 현재 활성 모듈 (주요 개발 대상)
- **ILSOS_PrismaticScanner**: 참고 용도의 레거시 소스
- ILSOS_PrismaticGun: 미사용
- ILSOS_PrismaticCleanLaser: 미사용
**주의사항:**
- WeldingComponents와 Aurora 관련 코드 수정 시 반드시 사전 승인 필요
- 소스의 `config/` 디렉토리는 분석 시 참고할 것
- 모든 파일 수정 시 `docs/CODING_RULES.md` 확인 필수
- 한글 포함 파일 작성/수정 시 UTF-8 인코딩 준수

51
docs/ptop-architecture.md Normal file
View File

@ -0,0 +1,51 @@
# ILSOS_PrismaticPTOP 핵심 구조
## 폴더 구조 및 주요 컴포넌트
```
ILSOS_PrismaticPTOP/
├── EquipDef.cs ← ID 상수 정의 (Device/Motor/Sequence/Recipe)
├── EquipmentSetup.cs ← 통합 제어 (초기화, 이벤트 구독, 시퀀스 시작)
├── Alarm/ ← 알람 코드 및 매니저
├── Device/
│ ├── ACS/ ← ACS 모션 제어 (X/Y축)
│ └── PLC/ ← PLC 통신 로직
├── Models/ ← 장비 특화 모델
├── Process/ ← ProcessManager, CellInfo, WeldingData
├── Recipes/ ← MainRecipe, RMSHandler
├── Sequences/
│ ├── Monitoring/ ← 알람/상태 모니터링 시퀀스
│ ├── SeqAutoRunPrismaticGunStageA/B.cs
│ └── SubSequence/
│ ├── StageA/ ← Load, Weld, Unload, HeightMeas
│ └── StageB/ ← Load, Weld, Unload, HeightMeas
├── settings/ ← 세팅 정의 클래스
├── Tools/ ← 공통 유틸리티
└── Views/ ← WPF View/ViewModel
```
## 주요 ID 정의 (EquipDef.cs)
| 카테고리 | 예시 |
|---------|------|
| **DeviceIds** | ACS, MassFlowMeterStageA/B, HeightSensor, AJIN |
| **MotorIds** | ALineX/Y/Z, BLineX/Y/Z |
| **RecipeIds** | StageAMainRecipe, StageBMainRecipe |
| **SequenceIds** | SeqLoad/Weld/Unload/HeightMeas × StageA/B |
## 아키텍처 패턴
```
WPF UI Layer (Views/ + ViewModels)
↓
Machine Logic Layer (EquipmentSetup + Sequences + Process)
↓
Device Abstraction (AuroraDevices — 디바이스별 독립 모듈)
↓
Hardware Layer (ACS.SPiiPlusNET, Melsec, Serial/USB)
```
**기술 스택:**
- **이벤트 기반:** System.Reactive (Rx.NET)
- **의존성 주입:** AuroraEnv 글로벌 환경
- **메시지 큐:** String / Double / Int / JSON / LBAD 타입

26
docs/solution-structure.md Normal file
View File

@ -0,0 +1,26 @@
# 솔루션 구조
## ILSOS_All.sln 구성
```
ILSOS_All.sln
├── Machines/
│ ├── ILSOS_PrismaticPTOP/ ← 현재 활성 모듈 (3계층 아키텍처)
│ ├── ILSOS_PrismaticScanner/ ← 참고 대상 (레거시)
│ ├── ILSOS_PrismaticGun/ ← 미사용
│ └── ILSOS_PrismaticCleanLaser/ ← 미사용
├── AuroraDevices/ ← 하드웨어 디바이스 드라이버 (22개 프로젝트)
├── AuroraComponents/ ← WPF UI 공통 컴포넌트
├── AuroraVision/ ← 비전 시스템 (MIL 기반)
├── WeldingComponents/ ← 용접 공통 기능
│ ├── WeldingCommon
│ └── LASAGUI
└── External/ ← Aurora 프레임워크 바이너리
```
## 주요 특징
- **모듈화:** 각 머신 모듈은 독립적인 디바이스 제어 및 시퀀스 구현
- **공유 레이어:** AuroraDevices, AuroraComponents 등으로 코드 재사용
- **표준 규칙:** WeldingComponents는 수정 불가 (승인 필수)
- **설정 참고:** 각 머신의 `config/` 디렉토리에서 설정 확인 가능

26
rules.md Normal file
View File

@ -0,0 +1,26 @@
# 협업 규칙
## 코드 & 분석
1. 주석과 변수명, 함수명을 맹신하지 말기
2. 수정은 무조건 승인받기
3. 코드 분석 및 작성은 serena를 통해서 사용
4. 코드 수정 시 한글이 안 깨지도록 수정할 것
## 문서화
5. `.md` 파일의 내용은 영문으로 작성하고 200줄 이상 넘지 않도록 작성
6. CLAUDE.md에는 라이브러리 형태로 각각의 주제에 맞는 `.md`를 `@import`하여 여러 `.md`를 사용
7. 작업을 완료할 시 `.md`에 필요한 부분이라고 생각되면 물어보고 `.md` 파일 갱신하기
## 커뮤니케이션
8. 대답은 한국어로 간결하게 해주고 내가 상세히 설명해달라고 할 때 자세한 내용을 알려주기
9. 질문에 대해 궁금한 사항이나 알아둬야 정확하게 해결할 수 있는 문제가 있으면 나에게 물어보기
10. 모르는 문제가 있으면 말을 지어내지말고 모른다고 말하기
11. 10분 이상 걸리는 작업은 중간에 어떤 부분을 하고 있는지 명시
## 출력 형식
12. 출력 문구 중에 수정할 내역의 줄은 초록 화살표(→)로 표시
13. 줄이 아닌 단어라면 주황색으로 표시
14. 기존 수정안하는 부분은 기본 색상(흰색)으로 표시
## 규칙 관리
15. 이 규칙들은 rules.md로 하여 CLAUDE.md에 import할 것