Task-시나리오 입력 계약과 PopulationSpec 구조 정리

[learncold]

Summary

FacilityLayout / PopulationSpec / EnvironmentState / ControlPlan / ExecutionConfig 입력 계약을 정리하고, PopulationSpec이 top-level population 계약이 되도록 시나리오 구조를 재작성한다.

Parent Issue

#3

Area

Domain

Target Sprint

Sprint 1

Why Needed

현재 문서는 PopulationSpec을 top-level population 입력 계약으로 고정하고 PopulationProfile을 그 하위 요소로 둔다. 기존 minimal ScenarioDefinition 입력만으로는 source-of-truth와 용어가 맞지 않는다.

Scope

• ScenarioDefinition authoring boundary를 다섯 입력 계약으로 분해한다.
• PopulationSpec 안에 PopulationProfile, initial placement, dynamic source를 포함한다.
• EnvironmentState, ControlPlan, ExecutionConfig 기본 경계를 정의한다.
• ScenarioVariation이 baseline full copy가 아니라 delta 구조가 되도록 정리한다.

Child Tasks

• Task-Occupant Source 동적 유입 구현 #248 Occupant Source 동적 유입 구현

Out of Scope

• template workflow 구현
• #100에서 다룸
• application UI 편집 화면 상세
• result artifact 구현 자체

Core Design Criteria

• PopulationSpec이 top-level contract이고 PopulationProfile은 하위 요소다.
• ScenarioVariation은 baseline 복제가 아니라 persisted delta를 표현한다.
• 입력 계약은 application -> domain -> engine 계층 경계를 유지한다.

Acceptance Criteria

• 시나리오 입력이 다섯 계약으로 정리된다.
• PopulationSpec이 profile/initial placement/dynamic source를 함께 소유한다.
• ScenarioVariation이 baseline delta 구조로 표현된다.

Related Docs

• docs/product/Product Backlog - Pathfinder 반영안.md
• docs/product/위험 정의.md
• docs/architecture/프로젝트 구조.md
• uml/domain-scenario-model.puml

Dependencies / Blockers

• #77의 validated FacilityLayout authoring 결과를 사용한다.
• Task-ScenarioVariation 중심 실행 흐름 구현 #26, Task-Behavior / Trigger / ControlZone 기반 control model 구현 #78, #79가 이 입력 계약을 기반으로 이어진다.
• #248에서 dynamic source의 실행 의미를 구체화한다.

Repository Checks

• I checked for an existing related issue or epic before creating or updating this task.
• I will keep the issue title aligned with the repository naming convention.