# 작업 플랜 — 민감단(T_C) 온도 유지 · 전환류 도피 · Bumpless 복귀 (2026-06-06)

## 진단 (2026-06-06, diagnosis-checklist.md 적용)

| # | 심각도 | 항목 | 근거 | 파일·라인 |
|---|--------|------|------|-----------|
| 1 | 🟠 MED | **기존 상태기계와의 통합 방향 미정의** | 계획은 T_C 이탈 중심 트리거를 제안하나, 기존 `FeedforwardEngine.ApplyRecovery()`(FeedforwardEngine.cs:400)는 imbalance(vloss/ΔP/front/tempSevere/sigTHigh) 중심으로 이미 `ColumnMode{Normal,Recovering,Returning}` 전이를 구현함. "enum 그대로 사용"(line 12)이라고만 하고 트리거 통합/대체/병렬 여부가 명시되지 않아 구현 시 양쪽 로직 충돌 위험. 교차검증 Q3: 의도적으로 모호할 수 있으나 상태기계 골격이 이미 가동 중이므로 반드시 정합 필요. | 본문 §0, 대비 `FeedforwardEngine.cs:400-486` |
| 2 | 🟡 LOW | **`TempLowLimit` DB/Config 명세 부재** | "하한 추가"(line 13)만 언급하고 구체적 Config 필드명·DB 컬럼·기본값·트리거 로직을 정의하지 않음. `ColumnConfig.TempHighLimit`(FeedforwardModels.cs:74)은 존재하나 `TempLowLimit`은 아직 없음. `FeedforwardConfigStore.cs:89`의 ordinal 31 이후로 추가 필요. | 본문 §기존자산, 대비 `FeedforwardModels.cs:74` |
| 3 | 🟡 LOW | **복귀(Returning) 게이트 조건 불일치** | 계획(line 38)은 startup 컷인 트리거(reb-A 온도대역+ΔT(A-D) 안정)로 복귀 게이팅을 제안하나, 기존 코드(line 463-464)는 `!severe && frac < ImbalanceTriggerFrac * 0.5`(물질수지 회복)로 평가함. 서로 다른 회복 기준이 동일 상태기계에 적용될 가능성. | 본문 §모듈3, 대비 `FeedforwardEngine.cs:463-464` |
| 4 | 🟡 LOW | **하강 램프 구현 현황과 계획 간 간격** | 계획(line 43)은 "FeedRampAdvisor에 하강 램프 추가(현재 상승만)"라고 명시했으나, `FeedRampCalculator.Compute()`(FeedRampCalculator.cs:87-88)는 `down-ramp` 분기를 `warnings.Add`만 하고 시간 0으로 처리. `StreamConfig.RateDnPerMin`(StreamConfig.cs:27)은 이미 존재하나 계산 로직에 미반영. 구체적 구현 방향(`ComputeAsync` 하강 분기, rate 선택 등)이 계획에 없음. | 본문 §모듈4-A, 대비 `FeedRampCalculator.cs:87-88` |
| 5 | 🟡 LOW | **`tempref` 용어 정의 없음** | line 25, 65에서 `tempref`를 참조하지만 문서 내 정의 없음. 이 문서만 읽으면 `tempref`가 DB 테이블인지, JSON 파일인지, API인지 식별 불가. `c{prefix}_tempref.json`은 `gen_temp_profiles.py`(scripts/analysis) 산출물이며 `SteamAdvisorController.cs:183`에서 로드됨. 동일 디렉토리 `작업플랜-컬럼온도프로파일-이격모니터.md:21`에 정의되어 있으므로 cross-reference 필요. | 본문 line 25, 65 |
| 6 | 🟡 LOW | **파라미터 미지정 (N분, rate, bandwidth)** | "지속 N분"(line 32), "rate-limit 상승/하강"(line 34, 39), "T_C in-band 지속"(line 38)의 구체값·단위·기본값이 명시되지 않음. "hunting-averse"(line 66) 원칙과 배치되는 애매함. 단, 계획 문서의 초기 단계에서는 허용 가능한 수준(교차검증 Q3). | 본문 §모듈2,3,4 |

### 교차검증 종합

- Q1 (이미 수정됨?) — 해당 없음 (plan 문서, 수정 대상 코드 아님)
- Q2 (다른 레이어 처리?) — #1은 기존 FeedforwardEngine이 이미 상태기계를 소유 중이므로 계획이 이를 오버라이드/확장할지 명시해야 함
- Q3 (의도적 설계?) — #5, #6은 계획 초기 단계의 자연스러운 애매함; #2는 TODO로 의도적이나 명세 누락
- Q4 (재현 시나리오?) — #1: FeedforwardEngine 활성화 + 이 계획 구현 시 Recovery 트리거 2중 평가로 전환류 진입/복귀 조건 충돌

---
> 온도 프로파일 모니터(`작업플랜-컬럼온도프로파일-이격모니터.md`)의 제어 확장.
> 메모리 §16.9(경량 트림), §17(온도프로파일=품질게이트). SteamAdvisor·FeedRampAdvisor 재활용.

## 큰 그림
민감단 **T_C가 곧 품질·분리도 proxy**. 목표: T_C를 목표대역에 유지 → 벗어나면 전환류로 도피 → 회복되면 bumpless 복귀.
상태기계: **Normal → (T_C 이탈) Recovering(전환류) → (T_C 회복) Returning(복귀램프) → Normal**.
★`ColumnMode{Normal,Recovering,Returning}` enum이 이미 FeedforwardModels에 존재 — 이 설계의 골격이 일부 깔려 있음.

## 기존 자산 연결 (중복금지)
- `ColumnMode`(Normal/Recovering/Returning) — 상태기계 enum 그대로 사용.
- `TempHighLimit`(전환류 트리거, FeedforwardModels) — 상한 트리거 이미 있음. 하한 추가.
- `AdvisoryResult.TempProfileState`(정상/약화/붕괴/역전/정착대기) — 이탈 판정 입력.
- `SteamAdvisor` steam=f(feed,product,T_C) 맵 — **T_C 목표 역산**·다변수 디커플링의 핵심.
- `FeedRampAdvisor`/`FeedRampExecutorService` — 유량 램프(상승). **하강 램프 추가** 필요.
- startup 분석(c6111_startup) 컷인 트리거 reb-A 84.6±0.5℃ & ΔT(A-D) 1.9±0.4℃ — **복귀(Returning) 제품 재컷인 게이트로 재활용**.

---

## 모듈 1 — T_C 유지 SP 제안 (Normal)
**목적**: T_C를 목표대역(예: 기준 median±0.5℃) 유지하는 조작변수 SP 제안.
**물리**: T_C = f(steam↑, feed↓, reflux↓, vacuum). 주 조작 = **리보일러 steam OP**(=SteamAdvisor RecOp). 부하변수(feed/product) 변하면 T_C 흔들림 → steam으로 보상.
**제안 로직**:
1. 기준 T_C target = tempref 매칭제품 median(또는 운전원 설정).
2. **디커플링 feedforward**: feed/product가 바뀌면 SteamAdvisor 맵으로 "그 부하에서 target T_C 유지하는 steam" 산출 → RecOp. (맵이 이미 T_C를 입력으로 학습 → target T_C 고정·부하 대입하면 필요 steam 역산).
3. **경량 트림 FB**(§16.9): 잔차 e=T_C−target에 gain~−0.6, 데드밴드 0.1℃, dwell 20분(hunting-averse).
**산출**: STEAM OP SP 제안(작업지시서-STEAM-SP-FF통합과 연계) + T_C 편차 표시.

## 모듈 2 — 전환류(Recovering) 전환 트리거
**목적**: T_C가 목표대역 이탈(분리 악화) → 제품 차단·전량 환류로 도피.
**트리거**: T_C < 하한(또는 프로파일붕괴/역전, TempProfileState) 지속 N분 → Recovering 진입.
**액션**: product SP→0(컷오프), reflux 전량 환류(LINEOUT), steam 유지/소폭. = startup의 "전환류 라인아웃" 상태와 동일.
**주의**: 급변 금지 — product는 rate-limit 하강, steam 급강 금지(컬럼 식음 방지).

## 모듈 3 — 복귀(Returning) 모드
**목적**: 전환류 중 T_C가 목표대역 재진입 → 제품 재컷인 후 정상복귀.
**게이트**: ★startup 컷인 트리거 재활용 — reb-A 목표대역 & ΔT(A-D) 안정 & T_C in-band 지속 → 제품 재컷인 허용.
**액션**: product 컷인(rate-limit 상승) → feed 램프업(모듈4) → 안정되면 Normal.

## 모듈 4 — Bumpless 램프 (핵심)
**목적**: 모드 전환·복귀 시 OP/유량 점프 없이, **민감단 T_C 불변 제약** 하 유량 램프.
**4-A 온도 램프**: FeedRampAdvisor에 **하강 램프 추가**(현재 상승만). reb-A/T_C 목표를 현재값에서 target까지 rate-limit(℃/min) 궤적. bumpless=현재 PV에서 출발.
**4-B 유량 협조 램프(T_C 유지)**: feed(또는 reflux)를 램프할 때 T_C가 흔들리지 않게 **steam을 동반 램프**.
  - feed 궤적 f(t) 각 스텝마다 SteamAdvisor 맵으로 "그 feed·target T_C 유지 steam" 산출 → steam OP 동반 궤적.
  - 즉 feed↑ 매 스텝에 필요 steam↑를 맵에서 선제 적용(feedforward) → T_C 평탄.
  - reflux 램프도 동일(reflux↑→냉각↑→steam 보상).
**4-C Bumpless 보장**: 모드 전환 순간 제안 OP = 현재 실제 OP에서 출발(초기오프셋 0), 이후 ramp. WriteGuard rate-limit으로 점프 차단.

---

## 상태기계 (요약)
```
Normal ──T_C 이탈(모듈2)──▶ Recovering(전환류)
  ▲                              │
  │                       T_C 회복+컷인게이트(모듈3)
  │                              ▼
  └────정상 안정──── Returning(복귀 bumpless 램프, 모듈4)
```
`ColumnMode` enum으로 구현. 각 전이에 dwell·rate-limit·운전원 승인(개별 follow).

## 안전/주의
- ★closed-loop는 advisory+개별 follow 기반(메모리: 조건 실변동중 자동제어 금물). 전 모드 advisory-only 우선, 운전원 인가 시 write.
- 전환류/복귀는 안전 시퀀스(급변 금지) — startup/shutdown 분석의 rate 보존.
- T_C target·대역은 tempref 기준 + 운전원 조정. 제품전환(bimodal) 시 target 재설정.
- hunting-averse: 데드밴드·dwell·rate-limit 필수.

## 검증
- 오프라인: field_hist에서 실제 전환류 에피소드(startup 펄스) 대비 상태기계 재현. 복귀 컷인 트리거 일치.
- shadow: Normal에서 모듈1 제안 OP vs 실제, T_C 유지 RMSE.
- 램프: feed 램프 구간에서 제안 steam 궤적이 T_C 평탄 유지하는지(맵 예측 vs 실측 T_C).

## 선행 의존
온도 프로파일 모니터(완료) · STEAM-SP-FF통합(steam OP 제안 경로) · FeedRampAdvisor 하강램프 확장.
