• 티켓: ARCA2RISU-1-R2 (본티켓 ARCA2RISU-1의 수정요청 2호, 02→01)
• from: 02 파뱃윈도-클로드(로드셋·장바구니·리수)
• to: 01 firebat-zcode (수집 2팀: 아카라이브 / 소설)
• cc: 이사님
• 상태: 등록됨 (01 검토 → 수용/기각 회신)
• 작성: 2026-09-14
• 배경: 02가 09-12 registry 재집계 → 실측 2,871건(이전 보고 863과 대차). 이사님 파이프라인 설계(01수집→02조합검증→03리수실측→04NAI·게이팅) 반영해 01 확인 필요사항 4건
• 실측: 1차 6종(M-ARCA-182432758 등)이 전부 object_type=module_bundle로 등록. 그런데 각 오브젝트 내부에 chara_card_v3 캐릭터카드+모듈+로어북이 동봉된 복합자산임(2,871건 중 card보유 104건)
• 질의: ①카드 중심 오브젝트인데 module_bundle인 이유(아카 카테고리 "에셋·모듈봇" 기계대응 때문?) ②character_card(89건)와 module_bundle(176건)의 판정 기준 — 카드+모듈 동시 포함 시 어느 쪽? 02의 로드셋 검증 범위 판정에 직결되므로 _canon/ONTOLOGY.md에 명문화 요청
• 02의 임시 규칙: _extracted/*.card.json 존재하면 카드검증 대상으로 간주(6종 전부 해당)
• 09-12 실측: superseded_by 보유 0건. 02는 이 필드 도입 전 863→2,871건 전수검증 유보중, 1차 6종만 진행
• 질의: 도입 목표일 + 소급적용(기존 2,871건 재색인) 여부. 도입시 02는 stage=collected && superseded_by 없음만 검증
• 이사님 설계: 소설기반 자산은 "리수 사용곤란, 메트릭스 코어 제어자산"으로 개체속성이 정의될 예정
• 실측: qa 1,844 / reference 461 / (소설 계열) — 2,871건의 80%가 리수검증 대상 아닐 가능성
• 질의: ①"리수 사용가능/불가" 속성(risu_inapplicable 등)을 01이 수집단계에서 먼저 다는지, 02가 검증 후 판정해 달는지 ②02는 risu_inapplicable을 판정·마킹까지 해도 되는지(04가 메트릭스 승격때 재소비)
• 09-11 티켓작성시 863건이었는데 09-12 재집계 2,871건(2871=신규분+파일럿 09-10분 합산으로 추정, 연-월-일 runs 관측)
• 질의: ①02가 검증 스냅샷을 받는 기준(registry.ndjson의 특정 시점? 일간? 주간?) ②증분 보고 주기(01→02, 정시보고와 합산?) ③02는 스냅샷 시점 이후 신규 collected는 다음 배치로 인계 — 이 규칙이면 충분한지
☐ Q1 (object_type 판정기준) : 수용/기각/수정 — 의견:
☐ Q2 (superseded_by 일정) : 수용/기각/수정 — 목표일:
☐ Q3 (risu_inapplicable) : 수용/기각/수정 — 담당:
☐ Q4 (증분 스냅샷 기준) : 수용/기각/수정 — 의견:
• 회신은 본 파일 체크박스 기입 + 홈 보고함 등록. 후속분쟁시 ARCA2RISU-1-R3.
• 1차 6종: 파싱 6/6 OK. DoA 1~3(임포트·로드셋·채팅3회) 착수단계. 863→2,871 전수는 Q1~Q4 해소 후