7.8 KiB
| name | description |
|---|---|
| analyze-ptop-implementation | 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 병렬)
- 예상 소요시간?
- 다음 상태로의 전이 신호는 어디서 오는가?
추적 대상:
-
PLC 호출
- 실제 API·주소는
Device/PLC/PLCController.Logic.cs와PLCController.Address.cs에서 확인한다. PTOP은 원시 주소 문자열이 아니라 enum 기반(eBitInput/eBitOutput/eWordInput/eWordOutput)이다. - 읽기 / 쓰기 / 폴링 지점을 각각
파일:라인과 함께 기록 - 주소·API 이름을 기억이나 추측으로 쓰지 말 것 — 반드시 소스에서 확인한 것만 적는다.
- 실제 API·주소는
-
Laser 제어
- 활성화 (SetPower, SetFrequency, etc.)
- 대기
- 정상 종료
-
OCT 스캔
- 스캔 시작
- 데이터 수집
- 스캔 종료
-
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 참조.
타이밍·주소·소요시간을 지어내지 않는다. 코드 상수에서 읽은 값(
파일:라인병기)이나 실측값만 적고, 둘 다 아니면미측정이라고 쓴다. 상태 전이·경합·인과를 코드로 확인하지 않고 서술하면 문장 앞에[추론]을 붙인다 (rules.md#15·#16).미측정(값 없음)과 축이 다르니 대체하지 말고 병기한다. 주석이 그렇게 쓰여 있다는 것은 확인이 아니다 (#1) — 실제 코드 경로를 따라가야 표기를 뗄 수 있다.
입력 조건
단독 호출 시: 생성할
_workspace/파일 목록을 사용자에게 제시하고 승인받은 뒤 시작한다 (rules.md#2). 오케스트레이터(orchestrate-ptop-harness)를 통해 호출된 경우는 이미 승인을 받았으므로 생략한다.
사용자가 다음 요청 시:
- "PTOP 시퀀스 로직 상세 분석"
- "SeqAutoRunPTOP이 PLC/Laser/OCT을 어떻게 제어하는가"
- "PTOP 타이밍 분석"
- "PTOP에서 에러가 발생하면 어떻게 처리되나"
- "PTOP의 성능 병목은"
출력 결과
- 상태 머신 다이어그램
- 타이밍 다이어그램 (시간축)
- Rx.NET 메시지 흐름도
- 에러 처리 매트릭스
- 성능 프로파일
- 최종 분석 보고서
주의사항
- 코드 라인 번호 기록 — "Line 245의 try-catch" 형식으로 정확한 위치 기록
- 데이터 흐름 추적 — 변수, 반환값을 따라가며 이해
- 시간 측정 — Thread.Sleep() / Task.Delay() / TimeSpan 찾기
- 예외 처리 — Exception 타입별로 분류
- 불명확한 부분 기록 — 추측 금지, 명시적으로 "불명확함" 표시
- 주석·변수명·함수명을 맹신하지 않는다 (
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).