---
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 전체 점검", "종합 분석", "구조 파악")은 `orchestrate-ptop-harness`를 쓴다. 맨손 "업데이트"·"다시 실행"만으로는 이 스킬을 고르지 않는다 — 대상을 먼저 확인한다.
---

# Analyze PTOP Architecture Skill

## 목표

ILSOS_PrismaticRD_PTOP의 **3계층 아키텍처 전체 그림**을 명확히 파악하고 문서화한다.

## 분석 단계
> **소스 루트 = `Machines/ILSOS_PrismaticRD_PTOP/`.** 이 문서의 상대 경로(`Sequences/…`,
> `Device/PLC/…`)는 모두 그 아래다. 저장소 루트의 동명 폴더 `ILSOS_PrismaticRD_PTOP/`은
> 빌드 산출물(.pdb)이므로 거기서 소스를 찾지 말 것.


### 1단계: EquipDef.cs & EquipmentSetup.cs 분석

**EquipDef.cs에서 수집할 항목:**
- `DeviceIds : CommonDeviceIds`에 **직접 선언된** 상수 (`MassFlowMeter` 등) + base에서 상속된 것
- `SequenceIds : CommonSequenceIds`에 **직접 선언된** 상수 —
  `SeqStreamTest`, `SeqEventQTest`, `SeqTestRun`, `SeqAutoRunComponentWeld`, `SeqAlarmMonitor`,
  `SeqStatusMonitor`, `SeqAutoRunTDC`, `SeqAutoRunPTOP` (8개)
- 커스텀 `DeviceIds` / `SequenceIds` / `SettingIds` / `StreamMessageNames`
  (`MotorIds`·`RecipeIds` 클래스는 **없다** — base `Common*`·레시피 매니저가 관리)

**EquipmentSetup.cs에서 수집할 항목:**
- `GetEquipmentName()` → 장비명 확인 ("ILSOS PrismaticRD_PTOP")
- `BuildMainStatusView()` → 표시되는 디바이스 (CellTracker, OCT)
- `OnSetAlarm()` 로직 → 알람 처리
- `OnStartUp()` 로직 → 초기화 순서
- SequenceBuilder 선언과 **실제 `register(...)` 여부는 다르다.** `EquipmentSetup.cs:206-218` 기준:
  - `_SeqAutoRunPrismatic_Builder` → **등록됨**(`:211`, `SequenceIds.SeqAutoRun`)
  - `_SeqAutoRunComponentWeld_Builder` → 대입은 되나 **등록 주석 처리**(`:212`)
  - `_SeqTestRun_Builder` → **선언만·대입 없음**, 등록도 주석(`:213`)
  - `_SeqAlarmMonitor_Builder` → **등록됨**(`:214`)
  - `SeqStatusMonitor.Builder()` → **필드 없이 직접 등록됨**(`:215`) — 빌더 필드만 보면 놓친다
  - `_SeqAutoRunPTOP_Builder` → **등록됨**(`:218`), 메인 시퀀스 (260605)

  > 목록을 그대로 옮기지 말고 **작업 전 `register(` 호출부를 실제로 나열해 대조하라** —
  > 주석 처리 여부까지 확인해야 "빌드되는 시퀀스"를 정확히 말할 수 있다.

**출력:** `_workspace/01a_equipdef_analysis.md`

### 2단계: Sequences/ 폴더 구조 분석

**주요 파일들:**
```
Sequences/
├── SeqAutoRunPTOP.cs           ← 메인 (분석 우선순위 1, 260605)
├── SeqAutoRunPrismatic.cs      ← 기존 (2026-06-18에 SeqAutoRunPrismaticScanner에서 개명)
├── SeqAutoRunComponentWeld.cs
├── SeqTestRun.cs
├── SeqStreamTest.cs
├── SeqEventQTest.cs
├── SeqWaitWeldOrChangePage.cs
├── LaserAngleOffsetSelector.cs
├── SequenceContextEx.cs        ← 컨텍스트 정의
├── SequenceManager.cs          ← 시퀀스 관리
├── Monitoring/
└── Manual/
```

> 트리는 참고용이다. **작업 전 `Sequences/`를 실제로 나열해 대조하라** — 이 목록이 낡았을 수 있다.

**각 시퀀스 분석 항목:**
- 용도 (주 시퀀스? 테스트? 모니터링?)
- 상태 머신 정의 (시작, 대기, 실행, 완료, 에러)
- 타이밍 (예상 소요시간)
- 호출하는 디바이스 목록
- 의존성 (다른 시퀀스에 의존하는가?)

**특히 SeqAutoRunPTOP.cs:**
- 상태 다이어그램 작성
- 각 상태에서 호출되는 디바이스/API 추적
- 타임아웃/재시도 로직

**출력:** `_workspace/01b_sequences_analysis.md`

### 3단계: Device/ 폴더 분석

**파일 구조:**
```
Device/
├── PLC/
│   ├── PLCContoller.Config.cs     ← 생성자·접속 설정만. 18줄, 주소 0건 (Controller 아님 — 저장소 오탈자)
│   ├── PLCController.Logic.cs     ← 읽기/쓰기 로직
│   └── PLCController.Address.cs   ← PLC 주소 맵의 진실원. 신호 상수 enum
└── IO/
    └── PAIX_PTOP.cs               ← IO 제어 (2026-06-18 개명)
```

> **동명 심볼 함정.** `WeldingCommon.Devices.Laser.PAIX_PrismaticScanner`(공유)와
> `WeldingComponents/WeldingCommon/Devices/PLC/PLCController.Config.cs`(공유, 오탈자 없음)는
> 개명되지 않고 그대로 존재한다. 머신 쪽 파일과 혼동하지 말 것.

**PLC 분석:** (모든 값은 `PLCController.Address.cs`의 enum에서 읽어 `파일:라인`과 함께 적는다)
- 실제 사용되는 주소 범위 — 추정하지 말고 enum 정의에서 확인
- 주요 신호 목록 (eBitInput/eBitOutput/eWordInput/eWordOutput)
- 읽기·쓰기 주기, 타임아웃 — 코드 상수 기준. 못 찾으면 `불명확 — 확인 필요`

**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`

보고서 골격은 [references/report-template.md](references/report-template.md) 참조.
모든 항목에 `파일:라인` 근거를 붙이고, 확인 못 한 내용은 `불명확 — 확인 필요`로 남긴다.

**단독 기동으로 `01`을 갱신했으면 stale 표기 의무는 여전히 네게 있다.** "아키텍처만 다시" 같은 요청은
이 스킬로도, `orchestrate-ptop-harness`로도 들어올 수 있는데 오케스트레이터 경유가 아니면 표기해 줄 주체가 없다.
`01`의 첫 줄에 `이번 실행에서 갱신됨(YYYY-MM-DD)` 을 적고, **이 파일에 의존하는 `02`·`03`이 이미 있으면**
그 두 파일 첫 줄에 `이전 실행 결과 재사용 — 01 갱신으로 정합성 미확인(YYYY-MM-DD)` 을 남긴다
(문구 3종 → `orchestrate-ptop-harness/references/data-protocol.md`).
**코드로 확인하지 않은 인과·해석은 문장 앞에 `[추론]`을 붙인다** (`rules.md` #15·#16).
`불명확 — 확인 필요`(값을 못 찾음)와 축이 다르니 대체하지 말고 필요하면 병기한다.
확인한 뒤에는 `[추론]`을 떼고 `파일:라인`으로 바꾼다.

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


사용자가 다음과 같이 요청할 때:
- "PTOP 아키텍처 분석해줘"
- "PTOP 계층 구조 검토"
- "PTOP에서 PLC, Laser, OCT가 어떻게 연결되어있는지"
- "PTOP 3계층 아키텍처 검증"

> "PTOP 전체 점검"·"종합 분석"처럼 **구현·빌드까지 함께** 보려는 요청은 이 스킬이 아니라
> `orchestrate-ptop-harness`다. 시퀀스 내부 동작만이면 `analyze-ptop-implementation`,
> 빌드/CI면 `optimize-ptop-build`.

## 출력 결과

- 5개 상세 분석 문서 (`_workspace/01a~01e_*.md`)
- 통합 보고서 (`_workspace/01_ptop_architecture.md`)
- 다이어그램 (3계층, 상태 머신, 이벤트 흐름)

## 주의사항

1. **코드 읽기 능력이 중요** — C#, WPF, Rx.NET 이해 필수
2. **불명확한 부분은 기록** — "이 부분은 왜 이렇게?"라는 질문을 명시
3. **Namespace** — 대부분 `ILSOS_PrismaticRD_PTOP.*`이고 옛 `ILSOS_PrismaticScanner`는 0건이다.
   단 **프로젝트 내 예외 3개**: `Sequences/SeqTestRun.cs:35`=`ILSOS_PrismaticRD_TDC.Sequences`,
   `Sequences/Monitoring/SeqAlarmMonitor.cs:22`·`SeqStatusMonitor.cs:11`=`WeldingCommon.Sequences`.
   네임스페이스로 grep하면 이 3개가 누락된다 — 파일 경로로 찾을 것.
   또한 **공유 프로젝트에는 `PAIX_PrismaticScanner` 같은 옛 이름 심볼이 그대로 남아 있으니** 머신 심볼과 혼동 금지
4. **260605 변경 이후 상태 파악** — SeqAutoRunPTOP이 최신 메인 시퀀스
5. **한글 주석 인코딩** — `docs/CODING_RULES.md` 확인
6. **주석·변수명·함수명을 맹신하지 않는다** (`rules.md` #1) — 위 3의 `PAIX_PrismaticScanner` 잔존이
   그 사례다. 이름이 계층·소속을 말해 주지 않으므로 등록부·구현 본문으로 확인한다.

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