---
name: analyze-ptop-implementation
description: ILSOS_PrismaticRD_PTOP의 구현 상세 분석. SeqAutoRunPTOP 시퀀스 로직, PLC/Laser/OCT/CellTracker 디바이스 호출 흐름, Rx.NET 메시지 체인, 상태 전이, 타이밍, 에러 처리를 분석하고 구현 개선안 제시. "PTOP 시퀀스 로직 분석", "PLC 통신 흐름 추적", "디바이스 호출 순서", "타이밍 다이어그램" 요청 시 사용. 구분 — 계층·의존성 구조는 `analyze-ptop-architecture`, 빌드/CI는 `optimize-ptop-build`, 셋을 함께 보려는 종합 요청은 `orchestrate-ptop-harness`. 맨손 "업데이트"·"다시 실행"만으로는 이 스킬을 고르지 않는다 — 대상을 먼저 확인한다.
---

# Analyze PTOP Implementation Skill

## 목표

ILSOS_PrismaticRD_PTOP의 **구현 세부사항**을 분석하고 최적화 기회를 식별한다.

## 분석 영역

### 1단계: SeqAutoRunPTOP.cs 상태 머신 분석

**수집 대상:**
- 상태 정의 (enum/class로 표현된 상태들)
- 상태 진입 조건
- 상태 내 액션 (동작)
- 상태 종료 조건
- 상태 전이 경로
- 타임아웃 설정
- 재시도 로직

**산출 형식: 상태 다이어그램**
```
[시작] 
  ↓ (전이 순서 — 시간축은 코드 상수 확인 후 기입)
[초기화] → [준비] → [용접] → [완료] → [정리] → [대기]
  ↓         ↓       ↓       ↓       ↓
[에러 처리] ← ← ← ← ← ← ← ← ← ← ← ←
```

### 2단계: 디바이스 호출 시퀀스 추적

각 상태에서:
- 어떤 디바이스가 호출되는가?
- 호출 순서는? (순차 vs 병렬)
- 예상 소요시간?
- 다음 상태로의 전이 신호는 어디서 오는가?

**추적 대상:**
1. **PLC 호출**
   - 실제 API·주소는 `Device/PLC/PLCController.Logic.cs`와 `PLCController.Address.cs`에서 확인한다.
     PTOP은 원시 주소 문자열이 아니라 **enum 기반**(eBitInput/eBitOutput/eWordInput/eWordOutput)이다.
   - 읽기 / 쓰기 / 폴링 지점을 각각 `파일:라인`과 함께 기록
   - 주소·API 이름을 기억이나 추측으로 쓰지 말 것 — 반드시 소스에서 확인한 것만 적는다.

2. **Laser 제어**
   - 활성화 (SetPower, SetFrequency, etc.)
   - 대기
   - 정상 종료

3. **OCT 스캔**
   - 스캔 시작
   - 데이터 수집
   - 스캔 종료

4. **CellTracker**
   - 셀 추적 시작
   - 위치 업데이트
   - 추적 종료

**산출 형식: 타이밍 다이어그램**
```
Time      <코드 상수 기준 눈금 — 실측이 아니면 눈금 대신 순서만 표기>
State     [<상태1>][<상태2>][<상태3>]
PLC       <호출>  <호출>
Laser     <호출>
OCT       <호출>
CellTrk   <호출>
```

> 축의 숫자는 **코드에서 읽은 지연 상수**이거나 **실측값**일 때만 넣는다.
> 둘 다 아니면 눈금을 빼고 호출 순서만 그린다 — 없는 시간축을 그리면 병목 판단이 오염된다.

### 3단계: Rx.NET 메시지 체인 분석

**수집 대상:**
- Observable 소스 (어디서 데이터가 나오는가?)
- 변환 (Select, Map, Filter)
- 구독자 (누가 소비하는가?)
- 에러 처리 (OnError, Catch)

**기록 형식:** 실제 소스에서 발췌한 구독 체인을 그대로 인용하고 `파일:라인`을 붙인다.

```
<발행 지점>            — 파일:라인
  └─ <연산자 체인>     — 파일:라인
    └─ <구독 지점>     — 파일:라인
```

> 이 스킬은 예시 코드를 제공하지 않는다. Aurora의 실제 이벤트 API(`EventPublisher`/`EventObservable`)는
> `docs/Aurora에이전트레퍼런스모음/01_concepts/event.md`에서 확인하고 저장소 코드로 대조하라.
> **그 폴더는 `.gitignore` 제외(로컬 전용)라 없을 수 있다** — 없으면 `External/Aurora/Aurora2.0_Guide.pdf`와
> 소스 코드를 직접 대조한다.
> 그럴듯한 가짜 체인을 적으면 이후 분석이 통째로 그 위에 쌓인다.

**산출 형식: 메시지 파이프라인 맵**

### 4단계: 에러 처리 로직

**찾아야 할 패턴:**
- Try-Catch 블록
- TimeoutException 처리
- PLC 에러 응답 처리
- 디바이스 오류 복구
- 폴백 경로 (재시도, 초기화 재개, 강제 종료)

**각 에러에 대해:**
- 감지 방법
- 처리 방식
- 복구 가능 여부
- 사용자 개입 필요 여부

### 5단계: 성능/안정성 분석

**성능:**
- 각 상태의 예상 소요시간
- 전체 시퀀스 총 소요시간
- 병목 구간 (가장 오래 걸리는 부분)
- 최적화 기회 (병렬화 가능한가?)

**안정성:**
- 데드락 가능성 (두 디바이스가 서로 대기?)
- 타이밍 이슈 (신호 도착 순서 의존?)
- 리소스 누수 (구독 취소 안 됨?)
- 상태 불일치 (PLC와 소프트웨어 상태 차이?)

## 통합 산출물

### 최종 보고서: `_workspace/02_ptop_implementation.md`
(**필수 산출물 2종**: `_workspace/02_ptop_implementation.md` · `_workspace/03_device_integration.md`)

보고서 골격은 [references/report-template.md](references/report-template.md) 참조.

> **타이밍·주소·소요시간을 지어내지 않는다.** 코드 상수에서 읽은 값(`파일:라인` 병기)이나
> 실측값만 적고, 둘 다 아니면 `미측정`이라고 쓴다.
> **상태 전이·경합·인과를 코드로 확인하지 않고 서술하면 문장 앞에 `[추론]`을 붙인다**
> (`rules.md` #15·#16). `미측정`(값 없음)과 축이 다르니 대체하지 말고 병기한다.
> 주석이 그렇게 쓰여 있다는 것은 확인이 아니다 (#1) — 실제 코드 경로를 따라가야 표기를 뗄 수 있다.

## 입력 조건
> **단독 호출 시**: 생성할 `_workspace/` 파일 목록을 사용자에게 제시하고 승인받은 뒤 시작한다
> (`rules.md` #2). 오케스트레이터(`orchestrate-ptop-harness`)를 통해 호출된 경우는 이미 승인을 받았으므로 생략한다.


사용자가 다음 요청 시:
- "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. **불명확한 부분 기록** — 추측 금지, 명시적으로 "불명확함" 표시
6. **주석·변수명·함수명을 맹신하지 않는다** (`rules.md` #1) — 이름이 말하는 동작과 실제 구현이
   다른 사례가 이 저장소에 실재한다. 판단 근거는 항상 구현 본문이다.

> **단독 기동으로 `02`·`03`을 갱신했으면 stale 표기 의무는 네게 있다.** "구현만 다시" 같은 요청은
> 이 스킬로도, `orchestrate-ptop-harness`로도 들어올 수 있는데 오케스트레이터 경유가 아니면 표기할 주체가 없다.
> 갱신한 파일 첫 줄에 `이번 실행에서 갱신됨(YYYY-MM-DD)` 을 적고, 의존 관계인 `01`이 낡았으면
> `01` 첫 줄에 `이전 실행 결과 재사용 — 정합성 미확인(YYYY-MM-DD)` 을 남긴다
> (문구 3종 → `orchestrate-ptop-harness/references/data-protocol.md`).

> 이 스킬은 10분을 넘긴다 — **단계 전환마다 지금 어느 단계인지 한 줄로 보고한다**(`rules.md` #10).
>
> 단독 호출로 마무리할 때: 보고는 `rules.md` #11~13 출력 형식(수정 줄=초록 화살표, 단어=주황, 미변경=기본색)을
> 따르고, 끝에 관련 `.md`를 갱신할 부분이 있는지 묻는다(`rules.md` #6).