← Index
Source: docs/history/2026-08-06-rabbit-history.md (auto-generated by scripts/generate-docs-html.mjs — edit the .md, not this file)

2026-08-06 — rabbit

관련 문서: docs/tasks/current-plan.md (새 계획 — Agentic AA 자율 루프) / docs/features/agentic-aa.md / archive/2026-08-06-current-plan-ap2-toss-aa.md (이전 계획 보관본)

current-plan.md 교체 — AP2/Toss/AA 구성요소 → Agentic AA 자율 루프

Cause: jay 요청 — 기존 계획 문서를 백업하고 비운 뒤, Agentic AA를 더 구체적인 데모로 새로 잡자. 기존 문서는 이미 다 만들어진 네 작업(AP2·Toss·§3 세션 키·§6 4대 요소)의 완료 기록이 되어 있었고, 경로도 /etc/* 기준이라 /poc/* 이전 이후 사실과 어긋난 상태였다.

Reasoning: "더 구체적인 데모"의 방향을 셋(자율 루프 / 4대 요소 심화 / AP2+AA 단일 시나리오) 중 jay가 자율 루프로 선택. 근거는 08-05에 jay 본인이 지적하고 AgenticPillars.tsx 주석에 남긴 것 — 지금 데모는 전부 사람이 버튼을 눌러 시작하므로 능력은 맞지만 자율성이 아니다. 요소를 하나 더 붙이는 건 같은 데모를 깊게 만들 뿐이고, 결정 루프를 붙이면 페이지가 증명하는 명제 자체가 바뀐다.

Change: 기존 current-plan.md를 docs/tasks/archive/2026-08-06-current-plan-ap2-toss-aa.md로 그대로 복사(삭제 없음)한 뒤 새로 작성 — /poc/agent 한 작업만 추적. 타이머로 깨어나 Chainlink Sepolia ETH/USD를 읽고 스스로 지출 여부를 판단하는 서버 측 루프, 금액+만료로 묶인 위임 안에서만 지불. 마일스톤 M1–M5, 미결정 사항 D1–D5(가스·키 보관·스케줄러·저널 저장소·규칙 vs LLM), 증명하지 못하는 것 §6까지 포함. docs/features/README.md는 AP2/Toss/PoCs 허브/7702 행을 ✅ 완료 + /poc 경로로 갱신하고, Agentic AA를 "구성요소(완료)"와 "자율 루프(예정)" 두 행으로 분리.

Result: 계획 문서가 완료 기록이 아니라 다시 "다음에 할 일"이 됨. 코드 변경은 없음. branch claude/agentic-aa-plan, 미커밋.

자율 루프 데모의 핵심 설계 — "건너뛴 판단"과 "만료 후 실패"를 보여주는 게 본체

Cause: 데모 형태를 정하면서, 결제가 성공하는 화면만 보여주면 결국 기존 4대 요소 카드와 같은 것(능력 시연)을 반복하게 된다는 문제가 드러났다.

Reasoning: 판단이 판단으로 보이려면 행동하지 않기로 한 틱이 기록에 남아야 한다. 그리고 lib/agent-scenarios.ts의 scheduled-operator가 주장하는 보장 — "안전은 신뢰가 아니라 산수" — 는 만료 이후에도 같은 코드가 계속 돌면서 계속 무해하게 거부당하는 장면에서만 눈으로 확인된다.

Change: 페이지를 버튼이 아니라 결정 저널로 설계 — 틱마다 관측값·평가한 규칙·판정·tx 또는 스킵 사유·누적 지출·남은 위임을 한 줄씩. 보여야 하는 상태를 셋으로 못박음(위임 내 무행동 / 위임 내 행동 / 만료 후 무해한 실패). M5는 코드가 아니라 증거 수집 마일스톤으로 별도 배정 — 위임을 실제로 만료시켜 그 저널을 캡처한다.

Result: 설계 문서에 반영. 저널이 스킵을 기록해야 한다는 요구가 D4(저장소) 결정을 강제한다 — 체인만으로는 스킵을 남길 수 없어 실제 저장소가 필요하다는 점도 문서에 명시.

PoCs 카드 추가(agent) + 카드 정렬 기준을 구현 날짜로

Cause: jay 요청 — 새 작업의 출발점으로 PoCs 페이지에 카드를 먼저 추가하고, 카드 순서를 구현 날짜 기준으로 정렬하자.

Reasoning: 페이지보다 카드를 먼저 쓰는 게 실제로 유용하다 — 카드의 purpose/howItWorks가 "이 데모가 증명하려는 명제"를 문장으로 못박아두면, 나중에 만든 페이지를 그 문장에 비춰 검증할 수 있다. 정렬은 기존 liveFirst(live 먼저)를 버리지 않고 2차 기준으로 날짜를 얹었다 — 순수 날짜순으로 하면 아직 열 수 없는 "soon" 카드가 동작하는 데모를 밀어내고 맨 위로 올라온다. 날짜는 "카드를 만든 날"이 아니라 "데모가 실제로 동작하게 된 날"로 정의 — AP2는 6월부터 스텁이 있었지만 Stripe 결제가 도는 건 08-04라 08-04.

Change: lib/demo-cards.ts에 date?: string(YYYY-MM-DD) 추가, liveFirst → sortDemoCards (① live 먼저 ② 같은 그룹 내 날짜 최신순 ③ 날짜 없는 카드는 뒤로, 배열 순서 유지)로 교체하고 호출부 둘(app/poc/page.tsx, app/til/page.tsx) 갱신. lib/poc-cards.ts의 live 카드 7개에 날짜를 채우고(7702·dvt 08-05 / ap2·aa·toss 08-04 / market 07-07 / xyz 07-01, git 이력에서 확인), agent 카드 신설 — status soon, 페이지 없음, 틱 흐름도(관측→판단→행동→기록, 스킵과 만료 거부를 같은 저널로 보내는 그림) 포함.

Result: tsc --noEmit 통과. 정렬 결과 확인 — erc-7702 · dvt · ap2 · aa · toss · hyperliquid · pbs, 그다음 soon 그룹 맨 앞에 agent. TIL 카드는 전부 soon이라 정렬 변경의 영향 없음.

/poc/agent 논의용 목업 — 만들기 전에 화면 모양을 두고 이야기하기

Cause: jay 요청 — 자율 결제 에이전트의 간단한 가상 데모 페이지를 만들어 함께 논의하자.

Reasoning: 계획 문서의 문장("스킵도 기록한다", "만료 후 무해한 실패")은 읽어서 동의하기는 쉬워도 화면이 어떤 모양이 되는지는 안 보인다. 각본 하나짜리 목업이 그걸 눈앞에 놓는다. 대신 목업임이 화면에서 즉시 보여야 한다 — 이 저장소가 다른 카드에서 지켜온 정직함의 기준이 그거라, 상단에 경고 패널을 두고 "체인·지갑·스케줄러 아무것도 안 붙어 있다"를 먼저 말한다. 카드는 soon 그대로 뒀다 — 허브에서 링크되지 않아 URL로만 들어오고, 아직 동작하지 않는 것을 "라이브"로 표시하지 않는다.

Change: app/poc/agent/page.tsx(목업 경고 · 무엇을 볼지 3가지 · 정해야 할 것 4가지 · 증명하지 않는 것 · 카드 기술 노트 재사용) + AgentJournalMock.tsx(손으로 적은 7틱 각본, 「다음 틱」으로 한 줄씩 공개). 각본은 스킵 2 → 지출 → 스킵 → 지출 → 만료 후 거부 2회로 끝난다 — 거부가 한 번이 아니라 두 번인 건 "계속 돌면서 계속 거부된다"가 요점이기 때문. 위임 패널은 남은 한도·만료·임계치·에이전트 주소를 KPI로 보여주고, 지출 틱마다 한도가 줄어든다. middleware.ts PUBLIC_PATHS에 /poc/agent 추가(논의 중 링크 공유용).

Result: tsc --noEmit + next build 통과, /poc/agent 4.63 kB. 페이지 하단의 "정해야 할 것" 4개(저널 열 구성 / 신호 선택 / 방문자 조작 범위 / 만료 상태 유지)가 다음 논의의 안건이다.

카드 배지에 세 번째 상태 "목업" — 눌리지만 라이브는 아니다

Cause: jay 요청 — 카드에서 페이지로 링크가 걸리게 하라. 기존 DemoCard는 status === "live" 일 때만 <Link>로 렌더해서, soon인 agent 카드는 페이지가 있어도 눌리지 않았다.

Reasoning: 카드를 그냥 live로 올리는 건 동작하지 않는 걸 동작한다고 말하는 것이고, soon인 채로 링크만 걸면 눌린다는 걸 아무도 모른다. 둘 다 사실과 어긋나서 상태를 하나 더 만들었다. 링크 여부는 페이지의 존재(href)가 정하고, 동작 여부는 배지가 말한다 — 두 가지가 원래 다른 질문이었는데 한 조건에 묶여 있었던 게 문제의 원인.

Change: app/DemoCard.tsx — 링크 조건을 isLive && card.href에서 card.href로 바꾸고, !isLive && href 조합을 "목업 / Mock" 배지로 렌더. lib/poc-cards.ts의 agent 카드에 href: "/poc/agent" 추가(status는 soon 유지), howTo도 실제 사용법에서 목업 안내로 교체 — "체크인 없이 각본을 한 틱씩 넘겨보라". TIL 카드는 전부 href가 없어 영향 없음.

Result: tsc --noEmit + next build 통과. 정렬 순서는 그대로(agent는 날짜가 없어 soon 그룹 맨 앞). 빌드 중 Prisma darwin-arm64 쿼리 엔진 에러가 보이지만 이 변경과 무관한 기존 로컬 환경 문제이고, 빌드 자체는 완료된다.

§8 신설 — Unity 시각화를 rabbit-hole 서브모듈로 (설계만)

Cause: jay 아이디어 — 에이전트가 행동하는 걸 보여주는 Unity 프로그램을 재미로 만들고 싶다. Unity 코드는 독립적이니 별도 저장소(rabbit-hole, 이미 생성됨·비어 있음)에 두고 rabbit에는 git 서브모듈로 붙인다. 구현이 아니라 계획 문서에 채워달라는 요청.

Reasoning: 재미 이상의 값이 있다고 판단해 그 근거를 문서에 적었다 — 저널에서 "거부됨"은 표 안의 빨간 글자지만, 장면에서는 열리지 않는 문이 된다. enforcer가 물리적으로 보이는 것. 다만 Unity WebGL은 표 하나를 꾸미는 데 수 MB 페이로드와 빌드 툴체인을 들이는 일이라 우려를 한 번 명시하고 넘어갔다(2D 캔버스면 1/10 비용). 그럼에도 진행하는 이유는 이 저장소에 Unity 트랙이 이미 존재하고(game.md, thirdweb.md의 Unity SDK) 그 자체로 포트폴리오 신호이기 때문.

핵심 설계 규칙 하나를 못박았다 — Unity는 멍청한 렌더러다. 저널 JSON만 받아 애니메이션하고 체인·키·RPC에 절대 접근하지 않는다. 이유가 둘: 체인으로 가는 두 번째 경로가 생기면 저널과 어긋날 수 있는데, 이 데모의 주장 전체가 "저널이 일어난 일의 기록"이라는 데 걸려 있다. 그리고 WebGL 빌드에 키가 들어가선 안 된다. 따라오는 제약("저널에 없는 건 장면에도 없다")은 한계가 아니라 의도다.

Change: docs/tasks/current-plan.md에 §8 추가 — 장면↔저널 3상태 매핑표, 렌더러 규칙, 서브모듈 전략 3안 비교(U1: 소스+CI빌드 / 소스+빌드산출물 커밋(권장) / 서브모듈 없이 릴리스 iframe), 배치(새 라우트가 아니라 /poc/agent의 저널⇄장면 토글), M5 이후 순서, 미결 U1–U4. 문서 상단 Scope와 목차도 갱신. rabbit이 빌드 시점에 필요한 건 Unity 소스가 아니라 WebGL 산출물이라는 점 — 소스만 서브모듈해서는 next build가 쓸 게 없다 — 을 U1의 출발점으로 명시. 이 질문은 docs/features/game.md가 이미 던지고 있던 것과 같아서, 한쪽만 정하지 말고 둘 다 같은 답을 쓰도록 연결해뒀다(U4: rabbit-hole이 이 프로그램 전용인지 jay의 Unity 작업 전체의 집인지 확인 필요).

Result: 설계만, 코드 없음. /poc/agent의 실제 구현(M1–M5)은 이것과 무관하게 진행되며, §8은 critical path 밖이라고 문서에 명시. U1이 나머지를 막는 결정.

홈 "수행 프로젝트" 섹션 → "대표 작업" — 두 갈래(프로젝트·PoC)에서 한 장씩

Cause: jay 요청 — 이 부분은 피처드 섹션이어야 하고, 피처드 항목은 수행 프로젝트와 PoCs 양쪽에서 뽑아야 한다. 프로젝트 쪽은 Verex, PoC 쪽은 AA(위임형 계정 & 세션 키)이며 나중에 자율 결제 에이전트로 교체 예정.

Reasoning: 레이아웃은 세 안(카드 둘만 / 카드 둘 + 기존 목록 유지 / 기존 구조를 두 줄로 복제) 중 jay가 카드 둘, 목록은 제거를 선택. 섹션 이름이 "대표 작업"인데 그 안에 대표가 아닌 항목 목록이 섞여 있으면 이름이 거짓말이 되기 때문 — 프로젝트 3건 목록은 /projects로 완전히 넘겼다. "나중에 agent로 교체"를 한 줄로 만들기 위해, 어느 PoC를 올릴지는 FEATURED_POC_KEY 상수 하나가 정하고 제목·설명은 카드에서 직접 읽는다(홈과 /poc가 같은 상수를 본다). 색을 갈라놓은 이유: 두 카드가 나란히 서는데 둘 다 Verex 브랜드색(인디고/푸시아)이면 같은 제품의 두 화면처럼 보인다 → PoC 쪽은 청록 계열(.featured-card-poc).

Change: app/home/page.tsx — 제목 "수행 프로젝트"→"대표 작업"/"Featured", 프로젝트 목록 제거, PoC 피처드 카드 추가. lib/poc-cards.ts에 FEATURED_POC_KEY = "aa" 신설. app/home/SessionKeyMark.tsx 신설 — Verex의 3D 구와 같은 64px 자리에 들어가는 열쇠 SVG(정적: 마크가 둘 다 움직이면 서로 경쟁한다). app/globals.css에 .featured-card-poc 변형 추가.

Result: tsc --noEmit + next build 통과. 자율 결제 에이전트가 실제로 돌면 상수 한 줄 ("aa" → "agent") 교체로 홈과 /poc 양쪽이 함께 바뀐다.

전체 보기 링크를 섹션 머리에서 대표 카드 아래 서브카드로

Cause: jay 지적 — "Projects → / PoCs →" 두 링크가 섹션 머리에 나란히 있으니 어느 링크가 어느 카드의 것인지 알 수 없다. 서브카드로 대표 카드 안에 넣어달라는 요청.

Reasoning: 소속을 글씨로 설명하는 대신 위치로 설명하면 된다 — 각 대표 카드 바로 아래에 그 갈래의 문을 붙이면 설명이 필요 없다. 대표 카드가 남는 높이를 먹게 해서(flex: 1) 두 칼럼의 서브카드가 같은 줄에 정렬되도록 했고, 서브카드는 배경 없이 테두리만 + 한 단계 작은 글씨 — 대표를 이기면 안 되기 때문. hover 테두리 색도 각자의 갈래 색을 따른다.

Change: .home-feat-col(칼럼 = 대표 + 서브카드), .featured-sub / .featured-sub-poc CSS 추가. app/home/page.tsx의 home-sec-head에서 링크 두 개를 빼고 각 칼럼 하단에 서브카드로 이동. .home-split > .featured-card 선택자는 중첩이 생겨 .home-feat-col > .featured-card로 교체.

Result: 빌드 통과. 도중 .next 타입 캐시가 깨져 route.ts not found 타입 에러가 났고, rm -rf .next 후 정상(코드 문제 아님 — 08-05에도 같은 증상 기록됨).

전체 보기로 나가는 문을 아예 제거 — 두 시도 다 어색했다

Cause: jay — 서브카드가 어색하니 그 부분만 빼라, 섹션 구성은 나중에 직접 다듬겠다. (나머지는 괜찮다는 확인도 함께.)

Reasoning: 같은 요소를 두 가지 방식으로 시도했고(섹션 머리의 작은 링크 두 개 → 대표 카드 아래 서브카드) 둘 다 어색했다. 세 번째 변형을 내가 또 추측하는 것보다, 자리를 비워두고 jay가 직접 정하는 게 맞다. "그 부분만" 이므로 대표 카드 두 장·색·마크·FEATURED_POC_KEY 구조는 그대로 두었다.

Change: app/home/page.tsx에서 서브카드 두 개 제거하고 칼럼 래퍼(home-feat-col)도 함께 되돌려 home-split이 대표 카드 두 장을 직접 담게 함. app/globals.css의 .home-feat-col / .featured-sub / .featured-sub-poc 삭제하고 .home-split > .featured-card 선택자 복원. 현재 홈의 대표 작업 섹션에는 전체 보기로 나가는 링크가 없다 — 의도된 공백.

Result: tsc --noEmit + next build 통과. 죽은 CSS 클래스 없음(grep 확인). /poc·/projects 자체의 피처드 섹션은 영향 없음.

/poc 상단에도 피처드 — /projects와 같은 구조로

Cause: jay 요청 — PoCs 페이지에서도 피처드 항목이 /projects처럼 맨 위에 보여야 한다.

Reasoning: /projects는 이미 "피처드 한 장(Verex) + 아래 전체 목록" 구조를 쓰고 있어서, 같은 형태를 그대로 따르면 두 허브가 같은 문법을 갖는다. 피처드로 올라간 카드는 아래 그리드에서 뺐다 — 한 화면에 같은 카드가 두 번 나오면 피처드가 "고른 것"이 아니라 "복사된 것"으로 보인다. 홈과 같은 FEATURED_POC_KEY를 보므로 두 화면이 어긋날 수 없다.

Change: app/poc/page.tsx — 상단에 피처드 섹션(제목·설명에 더해 howTo 한 줄까지 노출, 카드보다 넓은 자리라 실행 방법을 미리 보여줄 수 있다), 그리드는 피처드를 제외한 나머지만.

Result: 빌드 통과. 현재 피처드는 AA 카드, 그리드는 10장.

TIL 카드 추가 — LMSR과 하이브리드 AMM

Cause: jay 요청 — 하이브리드 AMM과 LMSR로 카드 하나를 추가하되, 그날 나눈 대화의 내용을 따를 것. 출처는 verex Phase A 마켓메이킹 논의(콜드 스타트, b·ln(n) 상한, Polymarket이 AMM을 폐기한 이유, 정보/무지 거래자와 스프레드).

Reasoning: PoCs가 아니라 TIL에 넣었다 — TIL의 정의가 "그날 배운 것을 다시 구현하는 코드 데모(수학 공식·알고리즘·서비스 연동)"이고 LMSR 비용 함수는 정확히 수학 공식이다. PoCs는 돌려볼 페이지가 딸린 데모 쪽이라 성격이 다르다. 옮기고 싶으면 배열만 바꾸면 되는 한 줄 작업. 카드의 관점을 "LMSR은 좋은 설계다"가 아니라 **"설계에는 유효기간이 있다"**로 잡았다 — Polymarket이 AMM을 폐기한 사실이 이 설계의 흠이 아니라 만료일이고, 자기가 그 날짜의 어느 쪽에 있는지 아는 게 요점이기 때문. 그 편이 카드 하나로 배울 값이 크다. verex의 결정 사항은 여기 옮기지 않았다 — 개념 카드이지 verex 작업 항목이 아니다(주석에도 명시).

Change: lib/til-cards.ts에 lmsr-hybrid-amm 카드 신설(status soon, 페이지 없음). 다이어그램 둘 — ① 콜드 스타트 루프와 유일한 출구(빈 호가창→가격 없음→…→빈 호가창, LMSR 사다리가 끊는 지점), ② 스프레드는 정보 거래자가 정하고 무지한 거래자가 지불하며, 정보 비율이 오르면 5%→2센트 / 15%→8센트 / 40%→어떤 스프레드도 불가로 가 호가가 사라지는 흐름. 계획한 페이지도 두 패널로 적어둠(공식 슬라이더 + 정보 비율 슬라이더).

Result: tsc --noEmit 통과. 이어서 jay 요청으로 상세 페이지까지 만들면서 카드는 live + href + date: 2026-08-06로 승격 — TIL에서 처음으로 열리는 카드가 됐다.

/til/lmsr-hybrid-amm 상세 페이지 — 대화에서 나온 분석을 통째로 옮김

Cause: jay 요청 — LMSR 카드에 상세 페이지가 있어야 하고, 내용은 그날 대화의 두 갈래 (① 스프레드를 누가 정하고 누가 지불하는가 ② Polymarket은 왜 안 쓰는데 우리는 왜 써야 하는가).

Reasoning: /poc/dvt(정독 노트)와 같은 성격이라 그 형식을 따랐다 — 지갑도 상태도 없는 읽기 전용 페이지이므로 status: "live"가 맞다(코드 데모가 아니라고 해서 "준비 중"인 건 아니다). 글의 뼈대는 대화의 결론을 그대로 유지했다: 스프레드는 정보 거래자가 정하고 무지한 거래자가 지불한다 → 정보 비율을 올리면 어떤 스프레드도 안 되는 지점에서 시장이 사라진다 → 그러므로 "시장이 존재한다는 것 자체가 무지한 흐름의 증거" → Polymarket의 네 반론은 전부 규모 반론이라 초기 단계에는 구속력이 없다 → 안전한 이유는 사다리가 그냥 지정가 주문이라 끄는 게 게시 중단뿐 이라는 것 → 실패 시나리오는 사다리의 영구화이고 이건 코드에 안 보인다.

Change: app/til/lmsr-hybrid-amm/page.tsx 신설 — 공식(C(q)=b·ln Σe^(qᵢ/b), 최악 b·ln(n)), 세 질문 표, 붕괴 사다리(5%/15%/40%), 넓은 스프레드의 두 해석(정직 vs 지대, 거래량이 신호), Polymarket 4대 반론, 규모 반론 대조표, 제거 가능성 설계, 실패 시나리오와 종료 조건, 한 줄 요약. 전부 ko/en 양쪽. lib/til-cards.ts 카드를 live로 승격하고 howItWorks를 "계획"에서 실제 내용 서술로 교체(인터랙티브 슬라이더만 계획으로 남김). middleware.ts PUBLIC_PATHS에 경로 추가.

Result: 빌드 통과, /til/lmsr-hybrid-amm 2.23 kB. 편집 중 howItWorks 문자열을 중간에서 끊어 깨뜨렸다가 파이썬으로 두 줄을 통째로 다시 써서 복구 — 긴 문자열은 부분 치환보다 줄 단위 교체가 안전하다.

Jay Chat RAG에 PoC·TIL 카드 전부 투입

Cause: jay 요청 — 방문자가 큰 프로젝트뿐 아니라 작은 데모들도 궁금해하니, Jay Chat이 PoC와 TIL을 전부 알게 하자.

Reasoning: lib/about-me.ts에 이미 어휘 기반 RAG(PROFILE/PROJECTS + content/profile/*.md)가 있어서 새 검색기를 만들 필요가 없었다 — 카드를 청크로 만들어 코퍼스에 넣으면 끝. 카드가 원본이라 페이지 설명과 챗 설명이 어긋날 수 없다는 게 부수 효과. 카드 하나를 청크 둘(영/한) 로 나눴다: 한 청크에 두 언어를 넣으면 글자수 상한에서 한쪽이 잘리고, 검색에 걸려도 절반이 엉뚱한 언어라 컨텍스트가 지저분해진다. 상태(status)를 반드시 함께 넣었다 — TIL 대부분과 /poc/agent는 아직 없거나 목업이라, 상태 없이 넣으면 챗이 없는 데모를 있다고 말하게 된다. 시스템 프롬프트에도 "상태를 지어내지 말고 정확히 따르라"를 명시.

Change: lib/about-me.ts에 demoChunks() + demoStatusLine() 추가하고 corpus()에 편입. buildAboutMeSystemMessage에 데모 상태 준수 지시 추가.

Result: 실측으로 검증 — "session key account abstraction demo" → poc:aa/poc:erc-7702, "LMSR 이 뭔가요" → til:lmsr-hybrid-amm 양쪽 언어 청크, "자율 결제 에이전트 데모 써볼 수 있나요" → poc:agent:ko(목업 상태 포함)로 정확히 검색됨. 중간에 발견한 버그: "what small demos has he built?"가 만들지 않은 카드들을 최상위로 끌어왔다 — 상태 문구가 "not built yet"이라 질문의 "built"와 어휘 매칭된 것. 부정문에서 그 단어를 빼고 "Status: planned — no page exists yet."로 바꿔 해결. 어휘 검색에서는 부정문에 쓰는 단어가 곧 오검색이라는 걸 문구에 주석으로 남김.

D1 결정 근거 — 스폰서 가스로 갈아타지 않고 7710을 유지

Cause: 08-05의 insufficient funds for transfer는 우발적 버그가 아니라 구조였다 — ERC-7710에서 세션 계정이 자기 트랜잭션을 직접 브로드캐스트하므로 Sepolia ETH가 필요하다. thirdweb paymaster로 옮기면 이 잡일이 사라진다.

Reasoning: 그런데 paymaster는 4337 스마트 계정에만 붙고, 4337 계정에는 이 데모의 본체인 금액/만료 enforcer 이야기가 없다. 위임의 의미론이 데모 그 자체이고 스폰서 가스는 편의다. 게다가 "에이전트가 가스가 떨어져 멈췄다"는 건 무인 에이전트가 실제로 죽는 방식이라, 저널의 정직한 실패 사례로 오히려 쓸모가 있다.

Result: 7715/7710 유지 + 세션 계정 1회 선충전을 권고안으로 문서화(D1). 확정은 jay 확인 후.

홈 프로필 연락 줄 — 맨 글자 링크에서 칩으로

Cause: jay — "LINKS / GitHub LinkedIn linked0@me.com" 부분이 어색하다, 스타일리시하게.

Reasoning: 세 가지를 바꿨고 그중 둘은 스타일이 아니라 내용이다. ① "LINKS" 라벨 삭제 — 링크 셋 옆에서 그 단어는 아무것도 설명하지 않는다. 뺄 액세서리. ② 글자를 플랫폼 이름에서 핸들로 — 마크가 이미 "어느 플랫폼"을 말하므로, 글자는 "거기서 그가 누구인가"를 말하는 게 정보량이 크다. "GitHub / LinkedIn"은 모든 포트폴리오가 똑같이 적는 말이고 linked0 / feelsogood는 그의 것이다. 방문자가 복사할 수 있는 값이기도 하다. ③ hover 색 = 목적지 자신의 색 (LinkedIn 파랑, 메일은 사이트가 이미 쓰는 인디고). 장식이 아니라 미리보기 — 색이 먼저 어디로 가는지 말한다. GitHub만 색을 주지 않았다: 마크 자체가 단색인 게 그 정체성이고, 셋 다 색을 주면 연락 줄이 신호등이 된다. 들어올리는 hover(translateY)는 일부러 쓰지 않았다 — 그 제스처는 피처드 카드의 것이고, 둘 다 쓰면 둘 다 흐려진다. 새 시각 언어를 만들지 않고 사이트가 이미 쓰는 재료(1px 테두리, --radius, --card, --ring)만 썼다.

Change: app/home/ProfileLinks.tsx 신설(인라인 SVG 마크 3종, aria-label에 플랫폼명+핸들 — 화면에는 핸들만 보이므로 스크린리더에는 둘 다 읽어준다). lib/home-content.ts의 links에 handle 필드 추가. app/globals.css에 .plinks/.plink + 목적지별 --accent-link(다크 테마 값 별도 — #0a66c2는 어두운 배경에서 안 읽힌다), :focus-visible 링. app/home/page.tsx에서 기존 라벨+링크 블록 제거.

Result: dev 서버 렌더 확인 — 칩 3개, 핸들 표기, "LINKS" 사라짐. 중간에 next start가 _document MODULE_NOT_FOUND로 500을 냈는데 .next 캐시 문제였고(08-05·08-06에 이어 세 번째), dev로 다시 띄우니 정상.