# Problems And Risks

이 문서는 현재 구조에서 prompt I/O 계약 관점으로 보이는 문제점과 리스크를 따로 정리한다. 코드 수정은 하지 않았다.

## P0. scene_detail ID 정책 충돌

관찰:

- `scene_detail` system prompt는 t2i_prompt 안에 `C##O##` 복합 ID를 직접 쓰라고 한다.
- 같은 버전의 schema description은 `t2i_prompt`에서 인물은 bare `C##`만 사용하고 `C01O02`는 금지한다고 설명한다.

영향:

- strict JSON은 통과해도 LLM이 어떤 ID 정책을 따라야 하는지 흔들린다.
- downstream `_resolve_refs_for_prompt`가 composite ref를 찾는 방식과 prompt text가 불일치할 수 있다.
- 참조 이미지가 "안 붙은 것처럼 보이는" 문제와 연결될 수 있다.

권장:

하나로 정해야 한다. 현재 scene_detail system prompt와 image ref 설계를 기준으로 보면 `C##O##`를 prompt에 직접 쓰고, `outfit_assignments`는 DB/UI sync용 중복 기록으로 두는 편이 더 일관적이다.

## P0. Asset readiness가 LLM prompt 품질과 분리되어 있지 않음

관찰:

프롬프트가 옳아도 참조 이미지 DB row, file_path, disk file, asset_type이 하나라도 틀리면 이미지 생성 단계에서 reference가 빠진다.

영향:

- 사용자는 "프롬프트 문제"처럼 보지만 실제 원인은 asset path/DB sync일 수 있다.
- text-only fallback이 자동으로 발생하면 일관성이 깨진다.
- step status가 completed여도 이미지가 기대대로 생성되지 않을 수 있다.

권장:

`scene_image_pipeline` 전에 deterministic `AssetReadinessCard`를 만들고, required ref 누락이면 image generation을 block/partial 처리해야 한다.

## P0. Silent failure는 creative pipeline에서 치명적

관찰:

이전 분석에서 DB insert 실패를 swallow하거나 step status가 completed로 남는 패턴이 있었다.

영향:

- 사용자는 완료된 줄 알고 다음 단계를 실행한다.
- downstream은 DB에서 asset을 못 찾아 reference 없이 생성한다.
- 문제 원인이 prompt인지 DB인지 구분하기 어려워진다.

권장:

asset-producing step은 expected vs registered vs disk found count를 exit verification으로 검증해야 한다. mismatch면 completed 금지.

## P1. Background state label / variant label 길이 정책 불명확

관찰:

background state는 plot-critical visual state를 담아 길어질 수 있다. 예: `night_body_blood_curtain_red_circle` 같은 값은 32자를 넘을 수 있다.

영향:

- LLM output은 schema상 valid지만 DB insert가 실패한다.
- 실패가 swallow되면 chain_bg asset DB row가 0개가 된다.

권장:

둘 중 하나를 선택해야 한다.

- DB를 `Text` 또는 넉넉한 `String(255)`로 확장
- prompt schema에서 `maxLength`를 강제하고 deterministic slugger가 짧은 ID와 긴 description을 분리

권장 구조:

```json
{
  "state_id": "night_body_01",
  "state_label": "night_body_blood_curtain_red_circle",
  "state_description": "night room with body, curtain drawn, red circular mark"
}
```

## P1. scene_detail이 너무 많은 판단을 떠안음

관찰:

현재 scene_detail prompt는 실제 실패 사례를 많이 반영해 매우 정교하다. 하지만 다음 판단들이 한 단계에 모여 있다.

- C##/C##O## ref policy
- body-part closeup 예외
- printed/mirror/TV 인물 예외
- background reference camera consistency
- close framing background skip
- physical object/body consistency
- violence intensity 표현
- simplification/partial focus/reframe

영향:

- prompt 길이가 커지고, rule conflict 가능성이 커진다.
- upstream이 모호하면 scene_detail이 다시 해석자가 된다.
- output schema description과 system rule이 어긋날 위험이 증가한다.

권장:

규칙을 제거하지 말고 upstream card에서 더 명확히 넘긴다.

예:

```json
{
  "render_strategy": "partial_focus",
  "id_policy": "common_noun_only_body_part",
  "background_reference_policy": "skip_close_framing",
  "continuity_elements_used": []
}
```

scene_detail은 이 policy를 조립만 한다.

## P1. Background와 foreground의 경계가 쉽게 섞임

관찰:

background_render는 사람이 없는 empty room을 만들고, scene_detail은 인물/소품/행동을 얹는다. 그런데 scene_detail prompt가 문, 창, TV, 책상 같은 background object를 다시 생성하게 만들면 중복이 생긴다.

영향:

- 문이 두 개 생김
- TV/창/커튼 위치가 바뀜
- 인물 scale이 background perspective와 충돌

권장:

RenderPromptCard에 다음 field를 명시한다.

```json
{
  "background_binding": {
    "bg_id": "cb_main_room_night_normal",
    "reference_usage": "exact_background",
    "objects_owned_by_background": ["door", "window", "table", "curtain"]
  }
}
```

scene_detail은 owned object를 새로 생성하지 않고 위치 anchor로만 사용한다.

## P1. Continuity fixed element가 framing과 충돌할 수 있음

관찰:

scene_consistency prompt는 이미 full/body-part overlap 문제를 다룬다. 하지만 이 규칙이 output 이후 deterministic하게 검증되는지는 별도 확인이 필요하다.

영향:

- dead body full pose와 wrist closeup이 같은 prompt에 함께 들어가면 몸이 중복 렌더링된다.
- 시체가 shot마다 움직이는 것처럼 보인다.

권장:

Validator:

```text
For each shot:
  group fixed_elements by bound_entity_id
  reject if framing_class full/upper_body and body_part_detail both apply to same shot
```

## P1. Evidence 없는 creative inference가 canon으로 굳을 수 있음

관찰:

시나리오 시각화에는 추론이 필요하다. 하지만 추론과 원문 사실이 같은 field에 섞이면 후속 단계는 둘을 구분하지 못한다.

영향:

- 원문에 없는 상처/혈흔/소품이 반복 삽입될 수 있다.
- 한 번의 hallucination이 continuity card를 통해 전체 scene에 퍼질 수 있다.

권장:

중요 decision에는 다음을 붙인다.

```json
{
  "source_facts": [],
  "visual_inferences": [],
  "creative_decisions": [],
  "confidence": "low | medium | high"
}
```

## P2. Prompt schema와 DB schema가 별도 진화함

관찰:

LLM schema는 JSON shape만 정의하고, DB schema는 저장 제약을 따로 가진다.

영향:

- prompt에서 valid한 string이 DB에서 truncation.
- optional field가 DB에서는 required.
- ID format이 prompt에서는 자유롭고 downstream에서는 regex 기대.

권장:

Prompt schema, pydantic/domain schema, DB schema를 한 곳에서 generate하거나 최소한 validator가 cross-check해야 한다.

## P2. Orphan/legacy code가 판단을 흐릴 수 있음

관찰:

현재 레포에는 disabled/deprecated background chain, old scene extractor, archived prompts, Gemini/GPT 비교 실험 코드가 많다.

영향:

- 검색 결과만 보면 실제 active flow와 legacy flow가 섞인다.
- 문서가 오래되면 현재 StepCatalog와 다를 수 있다.
- prompt 개선 시 잘못된 prompt version을 수정할 위험이 있다.

권장:

분석/문서화 기준은 active StepCatalog와 version_registry를 우선한다. `_archive`, `disabled`, `deprecated`, experiment scripts는 참고만 한다.

## P2. Human edit overlay 정책이 더 명시되어야 함

관찰:

사용자 편집이 재분석 후 보존되어야 한다는 제품 원칙은 있다. 하지만 Card 단위 override가 명시되어야 재실행 충돌을 줄일 수 있다.

영향:

- 사용자가 고친 shot/prompt/background가 force rerun에 사라질 수 있다.
- 어떤 수정이 AI 산출물이고 어떤 수정이 user override인지 추적이 어려워진다.

권장:

Card patch overlay:

```json
{
  "base_card_ref": "...",
  "patch": [],
  "preserve_on_rerun": true,
  "conflict_policy": "human_review"
}
```

## P2. Long context를 계속 직접 넣으면 비용과 drift가 커짐

관찰:

시나리오는 긴 문서이며, 중요한 정보가 흩어져 있다. 하지만 모든 단계가 fulltext를 크게 참조하면 비용과 drift가 커진다.

영향:

- 모델이 irrelevant detail을 끌어온다.
- scene-local decision에 다른 scene의 정보가 오염된다.
- prompt가 길어져 규칙 준수가 약해진다.

권장:

각 단계는 fulltext 대신 필요한 packet을 받는다.

- scene text
- previous/next brief
- project canon
- relevant entity cards
- selected shot cards
- continuity cards

fulltext는 evidence recovery나 high-level summary에만 제한한다.

## 요약 표

| 우선순위 | 문제 | 권장 조치 |
|---|---|---|
| P0 | scene_detail ID 정책 충돌 | system/schema description 통일 |
| P0 | asset readiness 부재 | image phase 전 deterministic preflight |
| P0 | silent failure | asset count exit verification |
| P1 | label length/DB truncation | DB 확장 또는 ID/label 분리 |
| P1 | scene_detail 과부하 | upstream card policy로 분리 |
| P1 | background/foreground 중복 | background-owned objects 명시 |
| P1 | continuity framing overlap | deterministic validator |
| P1 | evidence 없는 추론 | facts/inferences/decisions 분리 |
| P2 | schema/DB 불일치 | cross-schema validation |
| P2 | orphan code 혼선 | active catalog 기준 분석 |
| P2 | human edit 보존 | card override patch |
| P2 | long context drift | packetized prompt input |