야외 구조물 이미지 파이프라인 — 개발자 상세도

2026-07-31 기준. 시나리오 텍스트 한 편에서 야외 구조물의 확정 실사(씨드)가 나오기까지 어떤 스텝이 무엇을 근거로 무엇을 만드는지, 그리고 어디가 아직 비어 있는지를 적는다. 각 블록에 상태 표를 달았다 — 문서와 코드가 어긋나면 코드가 맞다.

구현·배선됨 모듈만 있음 (미배선) 설계만 (코드 없음) 실측 결함

0. 전체 조감 — 83스텝 중 어디를 다루는가

파이프라인은 step_manifest.py 의 order 로 정렬된 83스텝이다. 이 문서가 자세히 다루는 것은 21.7 ~ 21.93 구간(야외 구조물 계보)과 그 소비처다.

1. 야외 구조물 계보 — 현행 배선 구현·배선됨

1.1 대상 집합이 정해지는 곳 — 두 번 틀린 자리

“어떤 배경이 검색·씨드를 타는가”는 두 번 잘못 설계됐고, 두 번 다 자격을 판정하려 한 것이 원인이었다.

검색 대상 = collect_lane2_groups(lane, all_groups=<seed 와 동일 플래그>)
           - (place spec 결손 그룹)

1.2 outdoor_structure_form_reference — 검색·다운로드·이중 판정

왜 이 모양인가 (감독 말판 실험 6~13회차 + 금월도 2고 실측)

• 텍스트 검색만으로는 부족하다. web_search 기본값은 텍스트만 돌려줘 근거가 글로 요약돼 이미지 모델에 닿는다 — 표지판이 백색 무지로 비고 검색이 8→20회 반복됐다. 사진 자체를 받으려면 search_content_types:["image","text"] 를 켜야 한다.
• 검색을 지휘하는 지시문이 원본어여야 한다. 영어 지시문 안에서 “원어로 검색하라”고 하는 간접 방식으로는 검색이 관광지·타지역으로 샜다. 언어는 씬 원문에서 판정한다.
• 후보는 비교 선택 1회로 1장만 남긴다. 장마다 개별 판정하면 “그 중 하나”가 아니라 통과 집합이 된다.
• 심판 척도를 못박아야 한다. 지시가 없자 Gemini 는 0~100 을, GPT 는 사실상 0~10 을 써서 평균이 Gemini 단독 결정이 됐다(팩 v4 에서 0~100 명문화).
• 후보 0 판정이 너무 엄격했다. “서술의 요소가 한 장에 다 나와야 한다”를 요구해 3그룹이 죽었다 — 작품이 지어낸 장소의 구성을 찍은 사진은 웹에 존재할 수 없다(팩 v2 에서 완화).

1.3 outdoor_structure_seed — 저작·3변형·판정·수정

def _roll_prompt(lab: str) -> str:
    return roll_prompts[lab] if roll_prompts else prompt

1.4 run_multiroll_select 내부

2. 사전조사 (typology prior) 모듈만 있음 · 미배선

씨드 저작은 시나리오 원문 + place spec 두 가지만 근거로 쓴다. 그래서 둘 다 침묵한 항목은 모델의 통념이 메운다.

왜 siting 이 먼저인가

나머지 셋이 그 답에 매달린다. 같은 종류의 시설도 어떤 성격의 정주지에 서느냐로 예산이 갈리고 그래서 규모·구성이 갈린다. 입지를 가정한 채 규모를 물으면 틀린 유형을 조사해서 그 가정에 인용을 붙여 주는 꼴이 된다. validate_gap_output 이 “siting 문항은 첫 번째”를 강제한다.

naming 축의 별도 계약

검색 지시  : 이름의 조립 방식을 보고하라. 관측된 실재 이름은 예시로만 표시하라.
주입 블록  : "패턴이지 쓸 이름이 아니다" 경고를 naming 줄이 있을 때만 붙인다.
저작 권위  : ① 원문이 이름을 말하면 그것이 이긴다
             ② 침묵하면 관례의 조립 방식으로 짓되 성분은 작품 것에서
             ③ 관례가 없으면 오늘과 같이
validator : 저작 문안이 관측 예시와 문자열 동일하면 위반 (베낀 것)
            ★문자열 동일성만 본다 — 글자 패턴으로 의미를 판정하지 않는다

3. 편입 예정 설계만

3.1 전체 목표 계보 (5스텝)

전략 판정 — tri-state

strategy = {
  raw:       skeleton_then_look | direct | uncertain,   # 판정이 말한 것
  effective: skeleton_then_look | direct,               # 코드가 적용하는 것
  evidence:  [{scene_index, quote}],                    # 공급 씬 원문 verbatim
  reason_ko: str,
}

• uncertain 은 코드가 skeleton_then_look 로 보수 승격
• direct 는 비어 있지 않은 원문 provenance + 명시적 확신이 있을 때만
• 호출·검증 실패는 재시도 소진 후 fail-closed(direct 하강 아님)
• raw·effective 를 둘 다 영속 — 승격만 기록하면 감사에서 불확실성이 사라진다

3.2 skeleton — 구조 게이트와 회차 보존

관할 분리 — 변환절과 브리프가 충돌할 때

“변환절이 브리프보다 항상 우선”으로 뭉뚱그리면 브리프의 구조 사실까지 지워진다. 관할로 나눈다.

즉 면은 보존하되 글자는 비운다 — 브리프가 문안을 요구해도 빈 윤곽으로 그린다. 문안은 뒤 단계에서 복원된다. 실측: 이 문안을 넣자 두 그룹의 위반이 해소됐다.

게이트 축 — structure_checks[]

structure_checks: [{
  axis ∈ { mass, storey_count, access, openings, ground_connection, view_coverage },
  requirement_en: str,          # 이 구조물에서 무엇이 참이어야 하는가
  evidence: [{scene_index, quote}],
}]

축 이름은 구조의 보편 성질이지 유형 이름이 아니다. 무엇이 참이어야 하는지는 그룹마다 저작이 근거와 함께 쓴다 — 코드가 검사 항목을 지어내면 그 순간 유형별 규칙이 코드에 박힌다.

3.3 두 권위 합성

표면 참조는 어떻게 고르나

현재 25장은 “형태가 잘 읽히는가” 기준으로 고른 것이라 표면 권위로 쓰기엔 선택 기준이 어긋난다. 그렇다고 이름만 바꾸면 선택 목적이 여전히 form 이라 반쪽이다. 채택안 = 같은 후보 풀에 표면 기준 pick 계약을 새로 적용(검색 비용 0).

3.4 장소 표시면 재작화

코드는 표시물의 존재를 전제하지 않는다. 코드가 아는 것은 “이 장소를 알리는 활자나 표시가 들어가는 면” 까지이고, 그런 면이 사진에 있는지·읽힐 크기인지·고칠 값어치가 있는지는 전부 VLM 이 정한다.

다중 표시면 일관성 3겹

1. 모든 표시면이 같은 문자·색·서체·표장을 쓰고, 면의 비례에 따라 배치만 다르다
2. 한 면만 고치고 다른 면을 남기면 실패다
3. 없던 표시면을 새로 만들거나 키우지 않는다

typed no-op — “감사 가능”과 “결손 시 fallback”은 양립하지 않는다

effective_seed[gid] = {
  asset_id: <uuid>,   # no-op 이면 base seed UUID 를 명시적으로 적는다
  basis ∈ { applied, unchanged_not_required, unchanged_uncertain,
            unchanged_disagreement, unchanged_failed },
  reason_ko: str,
}

소비자는 map 결손 · 모르는 basis · 존재하지 않는 UUID 를 fail-closed 한다. producer 가 기록한 typed no-op 일 때만 base 를 쓴다. 이것이 place_mark 실패를 seed 실패로 전파하지 않으면서 조용한 하강도 막는 경계다.

4. 계약 · 지문 · 재사용

지문 3분리 (설계) — 획득과 선택의 수명은 다르다

★단일 지문에 선택 계약을 얹으면, 판정 문구 한 줄을 고쳤을 뿐인데 그룹 전체가 stale 이 되어 재검색이 돌고 후보 풀이 파괴된다. “재검색 없이 재판정”과 라운드 보존을 동시에 깨는 경로다.

정책 SOT (설계) — hash 는 validity gate 가 아니다

structure_seed_recipe ∈ { legacy, skeleton_look_v1 }
place_mark_mode       ∈ { off, v1 }
seed_critique_mode    ∈ { off, structure_preserving_v1 }

• 실행·claim 이전에 중앙 validator 가 불가능한 조합을 거부한다(fail-fast)
• manifest applicability 는 이 resolved policy 에서 파생한다
• 각 스텝 config_hash 는 resolved policy 를 기록만 한다

어휘 이행 (설계)

필드의 내용은 살린다 — 목표 문안은 재작화 스텝이 계속 쓴다. 바뀌는 것은 명칭과, “고칠 것인가”를 정하는 게이트가 저작에서 VLM 으로 옮겨간다는 것이다. 저작 시점 판정은 이미지가 없어 면의 존재·가독 크기를 알 수 없다.
현재 부채 13건이고 씨드 경로 밖으로도 번져 있다 — background_render · location_aerial · prompt_service · indoor_shared_pose_provider · visual_continuity_anchor_provider + 활성 팩 6개.

절대 제약 — 하드코딩 · 하드프롬프팅 금지

• 작품 고유명사 — 인물 · 장소 · 상호
• 업종 이름 — 특정 업종을 가리키는 낱말이 코드·프롬프트에 들어가면 안 된다
• 개념 자체 — 장소를 알리는 표시물의 통칭도 박지 않는다. 일반화 표현은 “장소를 알리는 활자나 표시가 들어가는 면”
• 대상 그룹 목록 — 상수 배열로 들지 않는다
• 글자·substring 으로 의미 판정 금지 — 의미 추출은 evidence-backed structured extraction 만
• 코드로 이미지에 그리기 금지 — 시각 요소는 항상 이미지 모델 몫

5. 실측 결함 대장

6. 구현 상태 매트릭스

설계 SOT = docs/superpowers/specs/2026-07-31-structure-skeleton-look-and-place-mark-production-merge-design.md
구현 계획 = docs/superpowers/plans/2026-07-31-structure-pipeline-foundation.md (계획 1/5)
이 문서는 코드보다 뒤처질 수 있다 — 어긋나면 코드가 맞다.