2026-08-18 — rabbit 작업 이력

소스 문서: 없음 — jay가 붙여넣은 뉴스레터(Numeraire, Sangam Bharti, "Sui is building Canton's alternative with Tessera", 2026-08-17)에서 나온 작업. 1차 출처는 Mysten Labs의 Tessera 발표(2026-08-10)와 Sui 공식 announcement. 전날 이력은 2026-08-17-rabbit-history.md.

PoC 카드 추가: 기밀 정산의 메타데이터 노출 — "금액을 가리는 건 쉬운 절반이다"

Cause: jay가 Tessera(Sui의 기밀 B2B 정산 네트워크) 분석 뉴스레터를 붙여넣고 PoC 항목 추가·머지를 지시.

Reasoning: 뉴스레터 자체의 논지는 "기술은 되는데 수요가 없다"(Canton은 600개 이상 기관·$6T, Sui의 스테이블코인 외 RWA는 $14M)인데, 그건 시장 관찰이지 만들거나 측정해서 답할 질문이 아니라 이 카탈로그의 카드로는 약하다. 그래서 축을 기술 쪽으로 옮겼다. 붙여넣은 자료를 검증하다가 Sui 자신의 발표 문구에서 카드의 뼈대를 찾았다 — "체인은 누가 누구에게 언제 냈는지를 보여준다. 금액은 ▦▦▦로 나온다." 이 문장이 무해한 절반으로 제시되는데, B2B 정산에서는 상업적으로 민감한 사실이 숫자보다 구조(공급업체가 누구인지, 계약이 언제 시작·종료됐는지, 대금이 늦어지기 시작했는지) 쪽인 경우가 많다. 게다가 비대칭이 있다 — 새어 나간 금액은 숫자 하나지만 공개된 그래프 간선은 되돌려 감출 수 없고 이후 결제가 계속 누적된다.

카드가 단순 비판이 되지 않도록 두 가지를 명시적으로 넣었다. ① 노출이 내재적이라는 것 — 암호화가 값에 걸린 이유는 체인이 여전히 어느 계정의 암호문을 갱신할지 지목해야 하기 때문이고, 그래프까지 가리려면 실드풀로 가야 하는데 그러면 기관이 사려는 감사 가능성이 깨진다. 점수를 따려 하지 말고 트릴레마로 적어 두는 편이 낫다고 판단해 그렇게 썼고, Canton을 비교군으로 세웠다(퍼미션드라는 대가를 치르고 그래프를 공개 원장 밖에 둠). ② 신뢰 모델 — Seal이 규제기관·과세당국·중재인에게 주는 범위·기한·취소 가능 접근은 컴플라이언스에 맞는 형태지만, 결국 기밀성이 임계 지분 보유자에게 조건부라는 뜻이다. 한 줄로 정리해 third-party-blast-radius 카드와 연결했다: 운영자가 취소할 수 있는 프라이버시 보장은 암호학적 성질이 아니라 정책이다.

Change: lib/poc-cards.ts에 confidential-settlement-metadata 추가. 배열에서 pet-clean-room 바로 뒤에 두었고 이유를 주석에 적었다 — 그쪽이 "끝내 읽히지 않는 데이터 위에서 계산하기"라면 이 카드는 "값만 가렸을 때 무엇이 새는가"라 짝이다. 측정 계획은 전부 합성 데이터 위에서 돌게 잡았다: 현실적 구조(공급업체 계층·net-30 주기·계절 변동·편입과 이탈·지연 시작)의 B2B 결제 그래프를 만들고 Tessera가 공개하는 것만(보내는 쪽·받는 쪽·타임스탬프, 금액은 범위조차 없이 제거) 공개한 뒤 공격 — 간격 규칙성으로 계약/일회성 분리, 간선 시작·종료일로 계약 개시·해지, 빈도로 거래처 중요도, 주기 미끄러짐으로 부실 신호. 산출물은 금액 데이터 0에서 이 추론들이 얼마나·어느 정확도로 복원되는가라는 숫자. 암호 기법(Ristretto255 위 Twisted ElGamal + ZK)은 웹 검색으로 교차 확인했고, 뉴스레터의 시장 수치는 카드 본문에 단정적으로 옮기지 않았다. status:"soon", date 없음 — Planned 기본값 규칙.

Result: npx tsc --noEmit 통과(exit 0). 카드 43→44, 목록 17번(pet-clean-room 바로 뒤). 생성 HTML 45개 전수 검사 — 신규 이슈 0건. 검출된 2건(docs/index.html의 div 28/27, file:/// 절대경로 링크)은 HEAD에도 동일한 기존 이슈.

PoC 카드 추가: 국가 간 결제 레일 상호운용 — "잇는 것은 라우팅 문제다"

Cause: jay가 BRICS의 즉시결제·CBDC 연결 검토 트윗("이것이 XRP Ledger가 극도로 중요해지는 지점")을 붙여넣고, 기존 관련 카드가 있으면 거기 덧붙이고 없으면 새로 추가하라고 지시.

Reasoning: 먼저 덧붙일 곳을 찾았고, 붙이지 않기로 했다. 가장 가까운 tokenized-money-banks는 "정산 자산을 은행 대차대조표에서 어떻게 다루나"(바젤 LCR/NSFR)를 다루는 특정 리포트의 정독 노트이고, 이 건은 "국가 간 레일을 어떻게 잇나"라 질문 자체가 다르다. 섞으면 그 카드의 주제가 흐려져서 새 카드로 만들고 서로 참조만 걸었다(배열에서도 바로 앞에 배치).

내용은 검증부터 갈렸다. BRICS 부분은 사실이다 — RBI 총재 발언으로 국가 즉시결제 시스템과 CBDC 연결을 검토 중이며 UPI·CIPS가 거명되고, 보도는 초기 단계에 기술·규제·거버넌스 장애물이 남아 있다고 적는다. 반면 보도 어디에도 공개 체인은 나오지 않는다 — "그래서 X 체인이 중요해진다"는 트윗이 스스로 채워 넣은 단계다. 출처 있는 주장과 덧붙여진 주장 사이의 그 간극이 rwa-multichain 카드를 쓰게 만든 그 간극이라, 같은 방식으로 카드의 출발점으로 삼았다.

그래서 질문을 한 단계 앞으로 옮겼다: 어느 원장이 채택되느냐가 아니라, N개 국가 결제 시스템을 연결할 때 실제로 공유되어야 하는 것이 무엇인가. 일을 넷(주소 지정·라우팅 / FX 가격 발견 / 유동성·선충전 / 최종 정산)으로 쪼개면 대부분이 메시징·표준 문제이고 BIS Project Nexus가 원장 없이 허브앤스포크로 이미 풀고 있다. 공유 원장이 진짜 논거를 갖는 유일한 다리는 정산 원자성(헤르슈타트 익스포저)이라고 판단해, 카드가 그 축 하나로 평가하도록 구성했다. 그래야 XRPL도 공정하게 평가된다 — 네이티브 DEX 자동 브리징과 에스크로는 메시징이 아니라 FX·PvP 다리를 겨냥하므로, 정직한 비교는 그 다리 대 Nexus식 허브 + 기존 RTGS이지 트윗이 하는 비교가 아니다.

Change: lib/poc-cards.ts에 cross-border-rail-interop 추가(tokenized-money-banks 바로 앞). 비교에 기준선이 이미 존재한다는 점을 살려 측정 가능하게 잡았다 — Nexus를 무원장 팔(유로시스템·말레이시아·싱가포르 테스트 시스템 연결, 휴대폰 번호 주소 지정, ASEAN 확장 중), mBridge를 원장 팔(중앙은행이 만든 다중통화 CBDC 정산 체인, 2024년 MVP)로 두고 **"허브 대비 무엇을 더 샀나"**를 묻는다. 측정의 핵심은 선충전 금액: 코레스 뱅킹의 진짜 비용은 수수료가 아니라 코리도마다 놀고 있는 노스트로·보스트로 잔고이므로, 코리도 하나를 원자적 PvP 유무로 모델링해 필요 선충전 유동성의 차이(코리도 거래량·정산 지연·FX 변동성에서 도출)를 구하면 논쟁이 아니라 숫자가 나온다. 측정이 오도되지 않도록 제약도 넣었다 — 여기서 채택을 결정하는 것은 처리량이 아니라 거버넌스(허브 운영자, 브리지 통화, 제재 시 처리, 회원 배제 가능성)라, 지연시간과 비용만 재면 틀린 것을 재게 된다. status:"soon", date 없음.

Result: npx tsc --noEmit 통과(exit 0). 카드 44→45, 목록 30번(tokenized-money-banks 바로 앞). 생성 HTML 46개 전수 검사 — 신규 이슈 0건(기존 2건 동일). BIS Nexus·mBridge와 BRICS 보도는 웹 검색으로 교차 확인했고, 확인되지 않은 사항(mBridge 거버넌스 변동 등)은 카드에 넣지 않았다.

워크스페이스 인덱스 파일명 수정 + Rabbit current-plan에 Roadmap status 신설

Cause: jay가 두 가지를 지적 — ① Workspace Index의 "Verex — Current Plan" 카드가 표시하는 파일명이 틀렸다 ② Rabbit의 current-plan도 Verex처럼 Roadmap status와 done/not-started 표기를 갖춰야 한다.

Reasoning: ①은 확인해 보니 링크가 아니라 라벨만 썩어 있었다 — href는 이미 current-plan.html을 올바로 가리키는데 card-path 텍스트만 jul-28-verex-design.md였고, 그 파일은 verex에 존재하지 않는다(docs/tasks/에 current-plan.md·jul-28-plan.md·jul-28-verex.md·jul-29-verex.md·jun-19-*.md만 있음). 링크가 멀쩡해서 클릭으로는 안 드러나는 종류의 오류라, 이후에도 잡히도록 카드 경로 전수 검사를 검증 스크립트에 넣었다.

②는 형식을 옮기기 전에 상태를 코드에 대고 감사하는 것이 먼저였다 — verex 표의 원칙이 "커밋 로그가 아니라 main의 코드 기준"이고, 그 원칙 없이 형식만 베끼면 그럴듯한 거짓 상태표가 된다. 감사 결과 M1–M5가 전부 미착수였다: app/api/에 agent 라우트가 없고(M2), app/poc/agent/에는 page.tsx와 AgentJournalMock.tsx뿐(M3은 목업만), 스케줄러 없음(M4). 여기서 걸리는 점 하나를 카드와 대조해 확인했다 — agent PoC 카드는 status:"done", date:"2026-08-12"인데, 08-12 이력을 보면 그날 한 일은 *"완료(done) 상태 신설"*이라는 문서 색인 정리이고 에이전트 구현 항목이 없다. 즉 그 done은 oz-relayer와 같은 완결된 사고실험 + 목업을 뜻하지 자율 루프가 돈다는 뜻이 아니다. 둘이 모순으로 읽히지 않도록 그 설명을 표 아래에 명시적으로 적었다.

Change: docs/index.html의 card-path를 verex/docs/tasks/current-plan.md로 교정. docs/tasks/current-plan.md에 ## Roadmap status 신설 — verex와 같은 표기(✅ done / ◐ partial / ❌ not started)로 M1–M5 + §8 Unity 사이드퀘스트 6행, 각 행에 파일 단위 근거를 적었다(추정이 아니라 확인한 것만). TOC에 항목 추가, 헤더의 Status: 줄이 표를 가리키게 수정, 그리고 전역 규칙대로 §0 Summary의 이력 포인터를 08-06 → 08-18로 갱신(08-06은 이 계획 자체의 설계일로 함께 남김). Logs 행 카드도 08-17 → 08-18로 올리고 verex 08-18 이력을 docs/history/로 미러, pnpm docs:logs로 60 → 62건 반영.

Result: Current Projects 카드 9개의 href와 card-path 텍스트를 모두 검사 — 깨진 것 0건(이전 검사는 href만 봤기 때문에 이 오류를 놓쳤다). npx tsc --noEmit exit 0. docs/index.html의 div 28/27은 HEAD와 동일한 기존 이슈.

Feature Designs 상태 갱신 — rabbit은 부분 재확인, verex는 실제 드리프트 2건

Cause: jay가 Rabbit·Verex Feature Designs 문서의 상태 갱신을 요청. 두 문서 모두 마지막 감사가 2026-08-03이었다.

Reasoning: 전체 재감사 대신 문서가 "없다"고 단정한 항목만 코드에 대고 확인하는 방식을 골랐다 — 드리프트는 대개 거기서 생기고, 근거 없이 상태를 바꿔 지어낼 위험이 없다. rabbit은 두 행이 여전히 정확했다: CI/CD는 .github/workflows/가 실제로 없어서 맞고, Agentic AA 자율 루프도 위 감사대로 ⬜가 맞다. 그래서 날짜를 통째로 갱신하지 않고 "이 두 행만 재확인했다"고 범위를 명시했다 — 나머지 행까지 새 날짜를 달면 확인하지 않은 것을 확인한 것처럼 만들기 때문. verex 쪽 상세는 2026-08-18-verex-history.md 참고(S9 CI/CD는 이미 존재, S6는 과소 기재였음).

Change: docs/features/README.md 상단에 2026-08-18 부분 재확인 문단 추가 — 재확인한 두 행과 각각의 근거, 그리고 자율 루프의 세부 상태는 이제 current-plan.md#roadmap에 있다는 포인터. 나머지 행은 2026-08-03 확인 날짜를 그대로 유지한다고 명시.

Result: rabbit 상태 문서가 코드와 일치하고, 어디까지 확인된 상태인지가 문서 자체에 적혀 있다. verex 문서 2건 수정은 형제 저장소에서 별도 커밋·머지했고, 어제 만든 동기화(pnpm docs:html → sync-verex-docs.mjs)가 그 변경을 rabbit 미러로 자동으로 끌어왔다(2 files updated).

Feature Designs 전수 재감사 — AI Chat 행이 실제로 틀려 있었다

Cause: jay가 Feature Designs 상태 갱신을 다시 요청. 앞 항목에서 한 것은 "문서가 없다고 단정한 두 행만" 확인한 부분 감사였고, 나머지 행은 2026-08-03 날짜를 그대로 둔 채 범위만 명시한 상태였다.

Reasoning: 범위를 적어 두는 것과 상태를 갱신하는 것은 다르다. 재요청은 표 전체가 현재 상태여야 한다는 뜻으로 읽는 것이 맞아서, 이번엔 전 행을 코드에 대고 확인했다 — 라우트는 app/**/page.tsx를 열거해서, 상단 메뉴는 app/Nav.tsx를 읽어서. 문서 텍스트는 근거로 쓰지 않았다.

한 행이 실제로 틀려 있었다. AI Chat 행은 *"라우트는 있으나 상단 메뉴에서 빠졌다(2026-08-01, Home으로 접힘)"*라고 적혀 있었는데, app/chat/은 아예 존재하지 않는다. 라우트가 있다가 메뉴에서 빠진 게 아니라 처음부터 별도 라우트로 만들어지지 않았고, 해당 기능은 Home에 임베드된 Jay Chat(app/home/page.tsx + app/api/jay-chat/route.ts)으로 출시됐다. "빠졌다"는 서술은 없는 라우트를 있었던 것처럼 만들어서, 나중에 이 표를 근거로 판단하면 잘못된 결론이 나온다.

나머지는 전부 유효했다: 상단 메뉴는 정확히 / · /portfolio · /projects · /game · /poc · /live이고(Verex 항목이 없다는 서술과 일치), /market은 lib/hyperliquid.ts·TradePanel.tsx로 Hyperliquid 거래가 실재하며, /xyz는 BundleSubmit.tsx·RelayDashboard.tsx로 C2·C4가 확인되고, /poc/aa는 session key·paymaster·batch가 모두 존재하며, /poc/ap2는 app/api/ap2/checkout/route.ts로 Stripe 경로가 있고, .github/workflows/는 여전히 없다.

Change: docs/features/README.md 상단의 부분 재확인 문단을 전수 재감사 문단으로 교체(무엇을 무엇으로 확인했는지 명시). AI Chat 행을 교정 — Menu 열을 ~~/chat~~ → Home으로 바꾸고, 이전 서술이 왜 틀렸는지와 실제 출시 형태를 행 안에 남겼다(고친 사실을 지우지 않고 기록으로 남기는 쪽).

Result: 표의 모든 행이 코드 확인을 거친 상태. 확인하지 않은 행이 없다. verex 쪽 10개 step 전수 감사는 2026-08-18-verex-history.md 참고 — 그쪽은 드리프트가 앞서 잡은 S6·S9 두 건뿐이었다.

current-plan을 verex 형식에 실제로 맞춤 — Next-work queue 신설 + §3에 상태 열

Cause: jay가 "Rabbit current-plan도 verex처럼 Roadmap status와 done/not-started 표기를 갖춰야 한다"고 다시 요청. 앞서 Roadmap status 표는 넣었지만, 그것만으로는 형식이 맞지 않았다.

Reasoning: 두 문서를 나란히 놓고 섹션 구조를 비교하니 빠진 것이 분명해졌다. verex는 Roadmap status → Next-work queue 두 축인데, rabbit은 앞의 하나만 있고 뒤가 통째로 없었다. 그리고 더 나쁜 문제가 하나 생겨 있었다 — 내가 넣은 Roadmap 표와 기존 §3 빌드플랜이 둘 다 M1–M5를 다루는데 한쪽에만 상태가 있어서, 표 두 개가 조용히 어긋날 수 있는 상태였다. 형식을 맞추는 김에 그 중복도 정리했다.

queue를 만들 때 M1–M5를 그대로 나열하지 않은 것이 판단이다. verex의 queue는 "지금 실제로 다음에 할 일"이지 마일스톤 목록이 아니라서, 같은 기준을 적용하면 M3는 D4(저널 저장, 미결)에, M4는 D3(스케줄러 호스트, 미결)에 막혀 있어 활성 작업이 아니다. 그래서 queue에는 막고 있는 결정 D2 하나 + 실제 착수 가능한 M1·M2 + 보류된 §8 만 넣고, M3–M5는 왜 빠졌는지를 명시했다. 그러지 않으면 결정 대기 중인 항목이 활성 작업처럼 보인다. §8은 verex의 dropped 항목 표기를 따라 취소선 + 보존으로 처리했다 — 설계는 이미 끝났고 U1(서브모듈 전략)만 미결이라 지울 이유가 없다.

Change: docs/tasks/current-plan.md에 ## Next-work queue 신설 — verex와 같은 Why now / Gate / Done when 3요소, "done when"은 코드 존재가 아니라 검증 게이트로 적었다(예: M2는 "curl로 두 번 연속 호출해도 안전할 때"). D2는 (you) + ⛔ BLOCKING으로 맨 위에 두었고, D1(가스)은 이미 결정된 사항이라 게이트가 아님을 명시. §3 빌드플랜 표에 Status 열 추가(M1·M2·M4·M5 ⬜, M3 ◐ 목업만)하고, 두 표가 어긋날 경우 코드 감사를 거친 Roadmap 표가 이긴다는 규칙을 표 위에 적었다. TOC에 queue 항목 추가.

Result: 문서 구조가 verex와 같아졌다 — Roadmap status(현황) → Next-work queue(다음 할 일) → 설계 본문. 상태 표기가 두 곳에 있지만 어느 쪽이 우선인지 문서가 스스로 말한다. 표 열 개수 정합성은 스크립트로 전수 검사(ragged 0건) — 첫 시도에서 헤더가 4열인데 데이터가 5열이 된 것을 그 검사로 잡아 고쳤다.

PoC 카드 추가: Senpi — "모델이 아니라 하네스"

Cause: jay가 Senpi(하이퍼리퀴드 위의 AI 트레이딩 에이전트) 요약을 붙여넣고 PoC 항목 추가를 지시. 붙여넣은 글은 다른 AI가 쓴 2차 요약이라, 공개 포트폴리오에 들어갈 카드인 만큼 주장부터 검증했다.

Reasoning: 검증 결과 요약의 핵심 주장이 전부 확인됐다 — 샤딩 키 + 시큐어 엔클레이브, SOC 2와 외부 감사 3건, 키 상시 내보내기, 마진 기준 TP/SL, 전략별 격리 서브월렛(내부 교차마진). 그런데 검증하다 요약에 없던 것 둘을 찾았고 그게 카드의 축이 됐다. 첫째, Senpi 자신이 Samurai를 **"하네스 — 시장 튜닝 모델을 결정론적 실행·리스크 기계로 감싸, 에이전트가 포지션을 환각하거나 스탑을 잊지 않게 하는 스택"**이라고 설명한다. 이건 이 카탈로그가 반대 방향에서 두 번 도달한 결론과 같다 — agentic-intent-veto가 "경계는 에이전트 바깥에서 강제되어야 한다"고 주장했고, 이 저장소의 current-plan D5도 같은 이유로 결정론을 골랐다. 둘째, 그 감싸개가 Senpi-ai/senpi-skills로 오픈소스(전략 템플릿 80개 이상)다.

그래서 카드를 제품 소개가 아니라 **"우리가 설계로 주장한 구조를 누가 실제 자본으로 돌리고 있고, 그 코드를 읽을 수 있다"**로 잡았다. 뽑아낼 질문도 하나로 좁혔다: 결정론적 층이 실제로 강제하는 불변식은 무엇이고 무엇은 문서로만 있는가. 제품 전체에서 가장 날카로운 디테일은 마진 기준 TP/SL이다 — 10배에서 "10% 익절"이 가격 1% 이동에 발동한다. 숫자가 틀린 게 아니라 단위가 사람들이 읽는 그것이 아니고, 이는 금액은 제약하되 구매는 제약하지 못하는 지출 한도와 같은 실패 양식이라 agentic-intent-veto와 정확히 짝이 된다. 측정도 간단해서(레버리지를 훑으며 표시 % 대 실제 가격 이동을 플롯) 카드가 에세이가 되지 않는다.

Change: lib/poc-cards.ts에 senpi-harness 추가, 배열에서 agentic-intent-veto 바로 뒤(설계 주장 ↔ 실제 구현 짝). 확인 항목을 싸게 끝나는 순서로 넷 배치 — ① 강제 집합(마진·명목가치·레버리지 한도가 신호를 거부한다는 형태가 intent-veto가 원한 그 형태라, senpi-skills에서 거부가 모델의 크기 확정 전인지 후인지를 본다) ② 단위 문제 ③ 격리(전략 A의 청산이 B에 닿는가, 격리가 하이퍼리퀴드 계정 수준인지 앱 수준인지) ④ 커스터디 긴장(샤딩·엔클레이브와 상시 내보내기는 서로를 잡아당긴다 — 내보낼 수 있다는 건 재구성할 수 있다는 뜻이라, 질문은 안전한가가 아니라 누가 어떤 정족수로 재구성하는가). 라이브 hyperliquid 카드와의 관계도 명시(그 위에 올라앉은 층). status:"soon", date 없음.

Result: npx tsc --noEmit 통과(exit 0). 목록 8번, docs/topics/pocs-senpi-harness.html 생성. 소스 diff는 +27줄, 삭제 0, 신규 키 1개, 중복 키 0건으로 확인. 생성 HTML 48개 전수 검사 신규 이슈 0건(기존 2건 동일).

PoC 카드 추가: 토요타 자체모집 ST 채권 — "토큰화가 실제로 없앤 것"

Cause: jay가 토요타파이낸스의 88억원 규모 자체모집형 토큰증권 기사(NADA뉴스 번역)를 붙여넣고 PoC 항목 추가·머지를 지시.

Reasoning: 기사의 프레임은 탈중개(증권사를 거치지 않고 발행사가 직접 모집)인데, 검증해 보니 한국어 보도에 없는 두 가지가 나왔고 그게 카드의 축이 됐다.

① 중개자는 사라지지 않았다. SMBC 닛코가 재무 어드바이저, 미쓰이스미토모은행이 사채관리자로 여전히 거래 안에 있다. 게다가 토요타가 자체 모집을 할 수 있는 이유는 토큰이 인가 요건을 없애서가 아니다 — ibet for Fin 컨소시엄은 ST 판매·유통을 금융청 등록 금융상품거래업자·등록금융기관으로 제한하고 토요타파이낸스가 그 자격을 가진 곳이라서다. 레일은 원래 인가받던 주체들에게 그대로 퍼미션드다. 그러니 실제로 사라진 것은 "중간상"이 아니라 훨씬 좁고 값어치 있는 것 — 증권계좌 개설 단계이고, 리테일 증권에서 퍼널이 죽는 지점이 정확히 거기다. 즉 이건 정산이 아니라 유통(distribution)의 주장이다.

② 1차 발행은 Progmat, 이번은 ibet for Fin. 1호와 2호 사이에 플랫폼을 갈아탔다는 사실이 기사에 없는데, 이게 가장 시사적이다 — 체인이 이 구조에서 교체 가능한 부품이라는 뜻이라, cross-border-rail-interop 카드가 도달한 결론("원장이 값을 하는 자리는 좁다")과 같은 자리에 선다.

규모도 카드에 적었다: 10억엔 ÷ 최소 10만엔 = 최대 1만 명. 토요타파이낸스에게 이건 자금조달이 아니라 채권의 옷을 입은 고객 참여 파일럿이다. 그리고 가장 새로운 부분은 원장이 아니라 혜택 구조다 — QUICPay 잔액 + 후지 스피드웨이 관람권·시승 추첨이라, 수익의 일부가 발행사 안에서만 상환되는 생태계 가치로 지급된다. 채권 데스크가 스프레드시트로 답할 수 없는 질문(혜택 포함 내재 수익률, 양도 불가 편익의 평가, 증권의 특성인가 마케팅 비용인가)이 여기서 나온다.

Change: lib/poc-cards.ts에 st-self-distribution 추가(cross-border-rail-interop 앞, tokenized-money-banks 앞쪽 묶음). 확인 항목 셋 — ① 참여자 장부(이 거래와 평범한 리테일 채권의 참여자·수수료를 나란히 놓고, "참여자가 줄었다"가 아니라 **"같은 참여자, 다른 역할"**을 검증. 수수료 스택이 그대로인데 고객 경험만 바뀌었다면 그 자체가 발견) ② 퍼널 산수(토큰 이전 경로는 계좌+KYC+입금, 이후 경로는 이미 연 앱 — 그 전환율 차이가 실험 전체의 값을 매긴다) ③ 혜택 포함 수익률. status:"soon", date 없음.

Result: npx tsc --noEmit 통과(exit 0). 목록 31번, 소스 diff +26줄·삭제 0·중복 키 0건. 생성 HTML 49개 전수 검사 신규 이슈 0건(기존 2건 동일). jay가 "함께 더 파보겠다"고 해서 후속 논의를 버틸 만큼 근거를 카드에 남겨 뒀다.