feat: 자산 관계 기반 구조적 데이터 검증 (template constraints)

[e7217]

배경

현재 자산/관계 등록 검증은 meta_handler.go의 inline 체크(필수 필드, relation_type 유효성)에 한정된다. 자산 모델이 풍부해졌음에도 구조적 제약(예: "온도 센서 자산은 반드시 어떤 장비에 partOf로 속해야 함", "두 자산이 connectedTo이면 같은 라인에 있어야 함")을 표현·강제할 방법이 없다.

이로 인해:

• 잘못된 관계 등록을 늦게 발견 (운영 데이터가 들어온 뒤)
• 자동 등록된 자산이 어디에도 속하지 않은 채 떠다님
• 어댑터가 잘못된 가정으로 동작

범위

1. 템플릿에 constraints 절 추가

   • 예시:

     name: temp-sensor
     resources: [...]
     constraints:
       required_relations:
         - type: partOf
           target_template: equipment
           min: 1
       forbidden_relations:
         - type: connectedTo
           target_template: factory

2. 자산/관계 등록 시 검증 hook

   • handleAssetCreate 후속 단계: 템플릿 constraints 평가
   • handleRelationCreate: 관계 추가가 양쪽 자산의 constraints를 위반하지 않는지 검증
   • 위반 시 reject + 어떤 제약을 위반했는지 명확한 에러 메시지

3. 기존 자산 점검 명령

   • CLI 서브커맨드 또는 NATS subject 1개: 현재 카탈로그 전체에 대해 위반 사항 리포트 (수정은 운영자가)

범위 외 (후속 이슈)

• 동적 룰 엔진 (F번 이슈로 흡수)
• 데이터 값 범위 검증 (이미 다른 검증 경로 존재)
• 기존 위반 자산 자동 마이그레이션·수정 (수동 운영자 작업으로 가정)
• 카디널리티 외 추가 제약(예: 시간 기반)

의존성

• 없음. feat: 온톨로지 활용 1단계 — 자동 컨텍스트 태깅 + 트리 질의 API #84 무관하게 진행 가능. 단 #84의 traversal API가 있으면 일부 검증(전이적 제약)이 쉬워짐 — optional.

핵심 설계 결정 (Plan에서 상세)

• constraints 어휘 — 어디까지 표현할 것인가 (cardinality, target_template, 양방향성)
• 검증 실패를 hard reject vs warning으로 처리할지 (운영 환경별 옵트인 필요할 수 있음)
• 자동 등록(Source=auto) 자산이 constraints를 만족 못 할 때 정책

계획 문서

상세 계획은 plan 파일로 별도 작성 예정.