LGES-OC5-PtoP-Welder/.claude/skills/analyze-ptop-architecture/SKILL.md

name

description

analyze-ptop-architecture

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 참조. 모든 항목에 파일:라인 근거를 붙이고, 확인 못 한 내용은 불명확 — 확인 필요로 남긴다.

단독 기동으로 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).