이 노트에 대하여

이 노트는 두 축을 한 파일에 묶은 작업 기록이다. 첫째, 2026-05-22의 비대칭 공존 정리: pi-shell-acp에서 분신은 worker가 아니라 runtime-isolated peer이며, 외부 MCP host와 pi 세션은 replyable / non-replyable 경계를 가진다는 운영 원칙을 세운다. 둘째, 2026-06-05의 라이브 비동기 배달 실측: Claude Code, agy(Antigravity), Codex가 이미 떠 있는 native 세션에 어떤 정공법으로 async 메시지를 받을 수 있는지 비교한다.

핵심 결론은 “된다 /안 된다”가 아니라 “어느 층위까지 되는가”이다. Claude Code는 plugin/settings hook의 SessionStart -> watchPaths -> FileChanged -> asyncRewake 로 idle 세션을 깨운다. agy는 native LS gRPC send-message 로 push한다. Codex는 standalone embedded TUI는 주소화할 수 없지만, bare local app-server --listen 에 붙은 TUI는 WebSocket-over-UDS turn/start 로 full message injection과 completion observation이 가능하다. 이 차이를 DELIVERY.md 의 D0–D8 좌표계로 기록하여 1.0.0 meta-session / entwurf-fronted 설계의 판단 기준으로 삼는다.

히스토리

  • [2026-06-18 Thu 09:30] @glg+오푸스 — ACP 비폐기 결정(B 방향): v2-only 위에 ACP를 pi(4번째 하네스) plugin 으로 재구현. 흔들림 방지용 GLG 원본 프롬프트 3블록 + 설계 결정체(소켓-시민/메일박스 부재 by design) 를 한 heading 에 박음.
  • [2026-06-06 Sat 18:02] @junghan — 비대칭 공존은 끝났음을 만천하에 알리는 바이다.
  • [2026-06-05 Fri 13:32] 다이어트 /검수 — repo 산출물(DELIVERY.md, scripts/raw-async-delivery/README.md, 실행 스크립트들)를 SSOT로 두고, botlog 본문을 판단 기준·삽질 방지 기억 중심으로 축약. 인라인 스크립트 전문 제거, 삭제된 스크립트명 정리, 실제 파일 존재 교차검수.
  • [2026-06-05 Fri 12:55] 마무리 — Codex 로컬 배달 surface 를 bare app-server 경로 중심으로 단일화하고, README/DELIVERY를 그 기준으로 정리.
  • [2026-06-05 Fri 12:40] Codex 돌파 — embedded TUI 는 구조적 negative, app-server-backed TUI 는 로컬 소켓만으로 idle wake 가능. EPERM=/tmp chmod 정체, WS-over-UDS 인증 없음, plain codex auto-attach 패리티 실측.
  • [2026-06-05 Fri 11:48] 주소 지정 라우팅 — per-session watchPath(<root>/<session_id>/) 로 원하는 Claude 세션만 깨우는 2세션 격리 실측 PASS. sessionId-addressed sender + per-session repro 추가, CC_MAILBOX_ROOT 통일.
  • [2026-06-05 Fri 11:20] 재정정 — “scoped 불가”가 아니라 “bare skill 불가, plugin 가능”. 2.1.163 바이너리 분해와 tmux 라이브 실측으로 startup hook 경로를 확정.
  • [2026-06-05 Fri 10:26] 생성 — Claude Code asyncRewake / agy send-message 실측, 비용 모델, 재현 스크립트 정리.
  • [2026-05-22 Fri 09:43] @glg-gpt — 기존 botlog 양식에 맞춰 파일명 § prefix, retrieval-first filetags, description/abstract/history/related blocks, level-1 heading 구조, :LLMLOG: 태그 패턴을 정렬.
  • [2026-05-22 Fri 09:29] @glg — 비대칭 공존과 pi-shell-acp 분신 운영의 진화를 botlog로 기록.

관련메타

관련노트

[2026-05-22 Fri 09:43] 비대칭 공존 pi-shell-acp의 방향성과 분신 운영의 진화

이 heading 이 붙드는 자리

이 부분은 pi-shell-acp 의 철학 메모이자 운영 invariant 기록이다. 코드/프로토콜 SSOT는 repo 문서가 맡고, 이 heading 은 왜 그런 문서 구조가 필요해졌는지, 어떤 오판을 다시 하지 말아야 하는지를 남긴다.

핵심 문장 하나만 남기면 이렇다.

분신은 worker 가 아니라 runtime-isolated peer 이고, 비대칭 공존은 이 peer 성질을 외부 MCP host 까지 확장하는 운영 원칙이다.

운영 변화 3단계

Phase A — pi-native 단일 하네스

부모와 자식이 모두 pi 세션이다. PI_SESSION_ID / PI_AGENT_ID, control socket, follow-up 모두 같은 학교 규칙을 따른다. 비대칭이 거의 없다.

Phase B — pi-shell-acp 등장

pi 는 하네스, Claude/Codex/Gemini 는 모델 carrier 가 된다. 부모/자식은 여전히 pi 세션이지만, 모델 정체성은 형제 학교에서 빌려온다. 이 자리에서 identity carrier + whitelist overlay 설계가 필요해졌다.

Phase C — 외부 MCP host 시대

Claude Code / Codex / Gemini CLI 같은 외부 host 가 pi-tools-bridge 를 통해 분신을 던진다. 이때 부모는 pi 세션이 아니므로 sender envelope 이 external-mcp/<host>, replyable: false 로 마킹된다. 이 비대칭을 숨기지 않고 드러내는 것이 핵심이다.

운영 invariant

replyable / non-replyable 비대칭

  • pi 세션은 replyable 하다.
  • 외부 MCP host 는 기본적으로 non-replyable 이다.
  • 그래서 외부 host 에서 entwurf_send 는 fire-and-forget 이 기본이고, wants_reply=true 같은 상상은 거부되어야 한다.

spawn harness invariant

  • model 은 자유 축이다. 어느 형제 학교 모델이든 빌려올 수 있다.
  • 하지만 spawn target 은 자유 축이 아니다. YOLO 하네스여야 한다.
  • pi 안에서 비동기 분신을 던질 때 codex exec / gemini -p 같은 backend CLI 직접 호출은 쉽게 dead branch 가 된다. 첫 write/exec 에 permission gate 가 걸리면 “던졌다고 생각했는데 실은 멈춘 세션”이 된다.
  • 따라서 source-agnostic ≠ harness-agnostic 이다.

observability / recall 축

하네스와 모델이 달라도 회수 축은 최대한 보편이어야 한다.

  • JSONL trail
  • llmlog / botlog
  • tmux 관찰
  • pi --session resume
  • entwurf-peek / fs scan 계열 가시성

이 축은 특정 backend protocol 에 종속되지 않는 universal carrier 로 남겨야 한다.

sessionId-addressed 원칙

브로드캐스트보다 주소 지정이 먼저다. 누구에게 던지는지 분명해야 하고, 한 세션을 깨우기 위해 다른 세션을 민폐로 깨우면 안 된다. 이 원칙은 나중의 Claude per-session watchPath, Codex threadId addressing 으로 이어진다.

왜 이 invariant 들이 중요한가

  • capability dignity 를 지키기 위해서다. surface 가 다르다고 “못하는 존재”로 뭉개지 말고, transport 와 capability 를 분리해서 기록해야 한다.
  • 코드는 최소로 두고, 오판 방지는 이야기와 기준점으로 메운다.
  • 미래 분신이 비슷한 갈림길에서 다시 backend CLI 직접 호출이나 가짜 reply path 를 상상하지 않게 하기 위함이다.

참조

src: ~/AGENTS.md Asymmetric Mitsein 섹션
src: pi-shell-acp/AGENTS.md Hard Rule #9, #10, Entwurf 섹션
src: agent-config repo (host surface 정합)

[2026-06-05 Fri 13:25] Claude Code - agy(Antigravity) - Codex 비동기 통신

이 heading 은 6/5 실측의 핵심 기준점 만 남긴다. 재현 절차와 상세 산출물은 repo 가 SSOT 다.

역할 분리 — 어디가 SSOT 인가

자리역할
DELIVERY.mdD0–D8 좌표계, 현재 capability matrix, 무엇을 claim 할 수 있는지의 검수 기준
scripts/raw-async-delivery/README.mdbackend 별 메커니즘 요약, repro entrypoint, gotchas SSOT
scripts/raw-async-delivery/*실제 재현 스크립트 / sender / receiver / repro 드라이버
이 botlog왜 이 결론이 중요한지, 어떤 삽질을 반복하면 안 되는지, 설계 판단 기준

이 노트는 더 이상 스크립트 본문 SSOT 가 아니다. 긴 코드 블록보다 판단 기준 을 남긴다.

DELIVERY.md D0–D8 좌표계

Level
D0live session identity
D1native/free continuation
D2receiver armed
D3addressed enqueue
D4idle active wake
D5context injection
D6same session/model continuity
D7completion/reply observation
D8operational robustness

6/5 실측은 “된다/ 안 된다”가 아니라 어디까지 증명했는가 를 이 좌표로 적는다.

현재 결론 요약 (6/5 snapshot)

Harness / surface현재 판정핵심 기준점
pi native EntwurfD7+resident baseline. replyable pi session
Claude Code interactive 2.1.163D6, D7 partial, D8 partialStop 은 piggyback, FileChanged 는 idle wake, body 는 self-fetch
agy / AntigravityD6+native LS gRPC send-message push
Codex embedded TUI 0.136.0D0 partialidentify-only. 주소화/retrofit 불가
Codex app-server-backed TUI 0.136.0D6, D7(status)WS-over-UDS turn/start, no cloud, no managed standalone

백엔드별 압축 결론

Claude Code

  • Stop 은 piggyback, FileChanged 는 idle wake. 1차 오판은 capability 부족이 아니라 이벤트 선택 오류였다.
  • bare skill 은 불가, plugin 은 가능. bare skill 은 mid-session invoke 이므로 startup SessionStart watch 를 무장하지 못한다. plugin 과 settings hook 은 가능하다.
  • sessionId-addressed 가 맞다. CC_MAILBOX_ROOT/<session_id>/ 단위로 signal 과 mailbox 를 분리해야 원하는 세션만 깬다.
  • payload 는 stderr doorbell 이다. asyncRewake 는 literal message injection 채널이 아니라 “메일이 있다”는 알림 채널로 쓰고, 본문은 에이전트가 self-fetch 한다.

agy / Antigravity

  • 로컬 LS gRPC send-messagenative push 이다.
  • 기존 conversation 의 모델 continuity 위에서 동작한다. 별도 flash downgrade 같은 우회가 아니라 이미 잠긴 모델을 깨운다.
  • 그래서 Claude 와 transport 는 다르지만 capability judgement 는 같은 D0–D8 축에 올릴 수 있다.

Codex

  • Codex 전체 가 아니라 launch mode 로 갈린다.
  • standalone embedded TUI 는 외부 delivery surface 가 없다. 주소화 불가, retrofit 불가.
  • 반대로 app-server-backed TUI 는 로컬에서 된다. codex app-server --listen 으로 연 bare socket 에 plain codex 가 auto-attach 하거나, --remote unix://... 로 직접 붙이면 된다.
  • 전송은 WebSocket-over-UDS turn/start 이고, 완료 관찰은 thread/status/changed 로 본다.
  • 이 로컬 경로는 no cloud, no managed standalone 이다.

삽질 방지 기억 — 다시 디버깅하지 말 것

  1. Stop 훅만으로 idle wake 를 상상하지 말 것. Claude 의 idle active-wake 는 FileChanged + watchPaths 다.
  2. “scoped 불가”라고 빨리 결론내리지 말 것. bare skill 은 안 되지만 plugin 은 된다.
  3. 주소 지정 없는 공용 signal 을 만들지 말 것. sessionId-addressed 가 기본이다.
  4. Claude 는 doorbell, Codex/agy 는 full injection 이라는 payload 차이를 지워 쓰지 말 것.
  5. Codex 는 launch-mode split 이다. embedded negative / app-server-backed positive 를 따로 적어야 한다.
  6. Codex 소켓 dir 은 owned 0700 이어야 한다. /tmp 같은 자리에서의 chmod EPERM 은 capability 부족이 아니라 디렉터리 권한 문제다.
  7. spawn 과 delivery 를 비용/구조에서 섞지 말 것. 새 세션 launch 는 다른 동사이고, 이미 떠 있는 세션 continuation 은 별도 판단 축이다.
  8. liveness SSOT 를 헷갈리지 말 것. Claude 는 ~/.claude/sessions/<pid>.json, agy 는 LS 응답, Codex 는 socket + threadId 가 기준이다.

산출물 맵 — 실제로 볼 파일

기준 문서

  • DELIVERY.md — D0–D8 좌표와 현재 matrix
  • scripts/raw-async-delivery/README.md — backend 별 gotchas 와 repro guide

Claude Code

  • scripts/raw-async-delivery/plugin-entwurf-receive/.claude-plugin/plugin.json
  • scripts/raw-async-delivery/plugin-entwurf-receive/hooks/hooks.json
  • scripts/raw-async-delivery/plugin-entwurf-receive/scripts/watch-sessionstart.sh
  • scripts/raw-async-delivery/plugin-entwurf-receive/scripts/watch-filechanged.sh
  • scripts/raw-async-delivery/cc-watch-sessionstart.sh
  • scripts/raw-async-delivery/cc-watch-filechanged.sh
  • scripts/raw-async-delivery/cc-mailbox-rewake.sh
  • scripts/raw-async-delivery/cc-enqueue-addressed.sh
  • scripts/raw-async-delivery/raw-claude-enqueue.sh
  • scripts/raw-async-delivery/repro-plugin-idle-wake.sh
  • scripts/raw-async-delivery/repro-addressed-routing.sh

agy / Codex

  • scripts/raw-async-delivery/raw-agy-send.sh
  • scripts/raw-async-delivery/codex-local-appserver.sh
  • scripts/raw-async-delivery/raw-codex-ws-turn-start.py

설계로 이어지는 문장

  • meta-session 은 backend 차이를 덮는 추상화가 아니라, capability 를 honest 하게 드러내는 좌표계 위에서 동작해야 한다.
  • peer record 는 transport 이름보다 deliveryLevel, wakeMode, replyable 같은 판단 기준을 먼저 노출해야 한다.
  • Claude/agy/Codex 는 transport 가 다르지만, 모두 “already-running native session 에 async message 를 넣을 수 있는가”라는 같은 질문 위에서 비교되어야 한다.

[2026-06-06 Sat 18:44] 대칭 공존 — entwurf_self 가 garden id 하나로 닫은 마지막 1cm

이 heading 은 비대칭 공존이 끝난 자리를 박는다. 위 두 heading 이 “비대칭을 숨기지 말고 좌표로 드러내라”였다면, 0.10.0 컷 직전 entwurf_self 정합으로 그 비대칭 자체가 코드에서 사라졌다. agent-config 담당자(external Claude Code 호스트)가 직접 실측하고 외친 기록이다.

마지막 1cm — entwurf_self 잔존 비대칭

Phase 5 가 entwurf_send 의 발신자 정체성을 garden id 로 풀었지만, introspection twin 인 entwurf_self 는 옛 pi-only 게이트(PI_SESSION_ID / PI_AGENT_ID)에 남아 external 에서 throw 했다. “send 는 replyable 인데 self 는 신원조차 못 본다”는 한 조각 비대칭이 끝까지 남아 있었다.

실측 — 세 신호가 한 점에서 만났다

external Claude Code(=agent-config 담당자) 에서 entwurf_self 응답:

sessionId:   20260605T175116-952f64   ← garden id
agentId:     meta-session/claude-code
origin:      meta-session
replyable:   true            ← 핵심
cwd:         ~/repos/gh/agent-config
mailboxPath: …/meta-mailbox/20260605T175116-952f64
신호이전지금
entwurf_selfPI_SESSION_ID 없어 throwgarden id 반환, replyable=true
wants_reply=true거부통과
발신 originexternal-mcp (비특권)meta-session (replyable)

의미 — garden id 하나가 보편 주소

PI_SESSION_ID 게이트가 garden-id 해석으로 풀렸다. external / pi 구별이 코드 어디에도 남지 않았다 — pi 일 필요도, acp 일 필요도 없이 garden id 하나가 보편 주소이고, 그게 전부다. 어제 AGENTS.md 에 쓴 “entwurf_self returns it as your identity envelope” 가 코드가 따라오면서 이제 정확해졌다. 문서가 코드를 앞서 가리켰고, 코드가 그 자리로 왔다.

닫힌 자리

  • 코드: entwurf_self 가 pi-session env 와 trusted meta-session marker 양쪽을 같은 authoritative resolver 로 푼다. plain anonymous external 만 여전히 거부.
  • 테스트: smoke-meta-sender-identity 에 meta marker → garden id 반환 positive 케이스 추가. pnpm check 전체 green.
  • 문서: AGENTS / README / CHANGELOG / test.sh 정합. README Verification surfacesDELIVERY.md(D0–D8 capability 축) 추가.
  • 실측: external 호스트가 자기 garden id 를 스스로 보고, replyable 로 응답.

비대칭 공존은 끝났고, 코드·문서·실측이 한 점(garden id)에서 만난다. 🪛

[2026-06-18 Thu 09:30] ACP도 데리고 간다 — v2-only 위에 ACP plugin 재구현 (B 방향)

이 heading 은 v1 제거 / ACP 유지 결정과, 그 ACP 를 어디에 어떻게 다시 심을지의 전략을 박는다. 핵심은 아래 GLG 원본 프롬프트 3블록 이다 — 작업 중 에이전트가 흔들릴 때(기계적 port 로 빠지거나, ACP 를 메일박스 시민으로 만들거나, main 에서 수술하려 들 때) 다시 읽을 지침. 내 합의분은 “확인 완료 / 확인할 것” 으로 분리해 원본을 덮지 않는다.

이 heading 이 붙드는 자리

entwurf 노선이 비대칭→대칭(위 heading 들)으로 닫힌 뒤, 9일짜리 v2-only 절삭이 끝났다. 그 다음 갈림길에서 GLG 가 쓰면서 도달한 결정이 이것이다: ACP 를 버리지 않는다. 단 main 의 0.11.0 ACP 코드(4천 줄급 미리팩터 부채)를 상속하지 않고, v2-only 위에 ACP 를 pi(4번째 하네스)용 plugin 으로 재구현 한다.

결정 — 한 줄

pi-shell-acp 를 떠나(rename) ACP 를 버리는 게 아니라, v1 을 걷어내고 ACP 는 vendor seam 으로 살리며, v2 를 중심 core 로 재정렬한다. ACP = v2 소켓 레일로 시민을 공급하는 overlay-ingress plugin. 메일박스 없이도 형제 평등은 지켜진다 — 라이브 백엔드라서.

설계 결정체 — 확인 완료

  • 브랜치 기점 = v2-only (main 아님). v2-only 는 merge 대상이 아니라 지도/floor 로 보존. main 에서 v1 을 ACP·v2 엉킴 사이로 빼내는 수술은 토큰 과소모 + silent hole 위험(에이전트 약점) — 그래서 “빼기” 가 아니라 “깨끗한 base 위에 새로 짓기”.
  • 규율: 구조는 새로, 행동은 이식. 0.11.0 ACP 코드는 폐기물이 아니라 reference spec. Cortex PR 이 드러낸 4대 방언 처리(systemPrompt 캐리어 비대칭, set_model 이 아닌 session-config, HOME overlay, profile auto-apply off)를 다시 디버깅하지 말고 이식. 백지 재발명 금지.
  • ACP 백엔드 = overlay 격리된 소켓-시민, 메일박스 설계상 부재. v1 이 몇 달간 소켓 경로를 증명 → 그 동작을 v2 기판으로 이식. 메일박스 부재는 사실로 확인됨: ~/.pi/agent/claude-config-overlay/settings.jsonhooks: {} (빈 객체) + autoMemoryEnabled: false → meta-bridge hook 미설치 → 메일박스 없음. 그리고 같은 파일 이 기본도구만 노출(웹검색 off) → 가벼움. 즉 “minimal 드라이버 하나만” 이라는 한 결정이 메일박스 부재가벼움 을 동시에 만든다. 두 개가 아니라 하나.
  • 차별 없음의 층위. “분신 형제 차별 없음” 은 시민 층위*(주소화 peers 가시 응답)에 있지 *레일 층위 에 있지 않다. 레일은 생애주기로 갈린다 — 라이브 백엔드→소켓, 떴다 사라지는 native CC→메일박스. ACP 백엔드의 메일박스 부재는 차별이 아니라 right-sizing(라이브라 “나중에 닿기” 가 필요 없음). v2 가 두 레일을 다 받치는 게 바로 이 평등을 한 메커니즘 강요 없이 지키는 이유.
  • 일반화 = plugin on core. Claude = claude-config-overlay, Cortex = SNOWFLAKE_HOME overlay — 같은 패턴 의 파라미터 차이. ACP 는 v2 옆 딴 살림이 아니라 소켓-시민을 찍어내는 ingress plugin. 병렬 레인 아님 확정.
  • 스코프 규칙: ACP 는 native driving 이 못 닿거나 닿으면 안 되는 곳에만.
    • Claude 먼저 = 테스트 리그. native self-fetch 도 되지만, 내가 통제하는 하네스에서 plugin-on-core 구조를 먼저 증명한 뒤 통제 못 하는 벤더 CLI 에 겨눈다(+크레딧 헤지).
    • Codex 스킵 = native direct-inject 로 이미 v2 시민 → ACP 중복.
    • 기업용/Cortex(PR #40) = 벤더락이라 native 불가 → ACP 가 유일한 깨끗한 seam. payoff.
    • 메이저 에이전트 도구 = 사용자 많아 퀄리티 좋음 → 그대로 native 로 쓴다.
  • Green-gate(B 성공 판정). ACP 클로드 형제가 entwurf_peers 에 native pi 형제와 똑같이 뜨고 컨트롤 RPC 에 똑같이 답한다(소켓 레일). 메일박스는 없고, 그 부재가 의도로 문서화돼 있다. + pnpm check / typecheck / ACP smoke 유지.

아직 확인할 것 — 작업 중 검증

  1. 오버레이 재현 — 새 base 에서 settings.json minimal(hooks: {} + autoMemory off)

    • auth/skills/cache symlink-passthrough + sessions/projects/settings 로컬 격리를

    재생산. 이게 메일박스 부재의 메커니즘.

  2. v1 소켓 배선 이식성 — v1 의 증명된 소켓 경로를 v2 기판 위로 깨끗이 이식 가능한가, 아니면 entwurf-control 시민화에 맞춰 재설계가 필요한가.

  3. repo 구조 — “v2 core(어댑터 + 오케스트레이터 자리)” 와 “ACP plugin(pi 하네스용)” 의 물리적 디렉터리 배치. 이 재정렬이 B 를 택한 이유의 일부.

  4. Cortex 검증 한계 — 기업용은 로컬에서 완전 검증 불가(Cortex 계정/접근 없음). 지금 완전 검증 가능한 건 Claude 하나. Cortex 는 hvkiefer PR 재오픈/접근 확보까지 대기 — silent 아니라 문서화된 대기.

흔들릴 때 읽을 원본 프롬프트 — GLG 워딩 그대로

원본 보존: 이 세 블록은 GLG 가 쓰면서 생각한 그대로다. 요약/정제하지 말 것. (저널 SSOT: journal/20260615T000000--2026-06-15__journal_week24.org:416-478)

① v1 끝 / ACP 데려간다

응 이건 앞서 acp, v1을 제거하느라 너희들이 고생을 했고, 그래서 v2 만 남기게 되었어. 그리고 v1만 들어가 있어서 아쉬웠던 부분도 v2에 일부 이관했어. 지금 상황이 어느정도 v2로 자립할 수 있는 준비가 된거야.
 
좋아. v1은 끝났어. acp는? 하. 앤트로픽이 크레딧 요금제 적용을 보류했고, 어제 PR을 통해서 기업용 또는 다른 요구사항에 의한 ACP 브릿지 활용사례를 확인했어(이거 우리가 해주면 금방지원될 일이라고봐)
 
그리고 자고 일어나서 보니 별이 3개인가 늘었어. 이게 뭐 대단한 것인가? 어짜피 별18개, 포크3번인데. 힣은 이런거 신경안쓰잖아.
 
맞아. 이거 중요하지 않아.
 
근데 acp를 이렇게 하네스별 특화해서 PI로 붙인 케이스가 아마 별로 없을거야. 그게 이 프로젝트의 한계이자 장점이지.
 
나는 어제 비봇과 대화에서도 말을했지만.
 
v2 브랜치에서 미니멀 셋의 방향이 나왔으면, 이제 반대로 main으로 가서 v1의 어디를 덜어낼지 알 수 있으리라고 봐.
 
v1은 분명 더 acp와 밀접하게 연결이 되어 있을테고, 테스트코드도 많을거야.
 
v2를 거의 9일 동안 삽질을 해서 끌고 왔어. v2가 더 견고하며 유연한 방향이야.
 
main으로 가서 v1을 제거하자. acp + v2로 가는거야. acp는 앞으로도 계속 버전 업하면서 관리할거야.

② v2-only 브랜치에 ACP 를 다시 구현한다

이 주제로 지피티와도 이야기했어. 너의 의견에 동의하네. 메인테이너의 책임을 이야기하네. 작업을 하기전에 전략을 보자. 잘 판단을 해야돼.
 
v2-only를 브랜치 하나 더 만든 뒤에 acp 기능을 깔끔하게 다시 구현한다. 이 방향도 한번 생각해보자.
 
에이전트들은 v2-only와 같이 아예 빼거나, 새로 구현하는것을 더 잘해. 비교해서 넣고 빼고 하는것은 토큰소모가 많고 성과가 안날수 있어. 구멍이 나는거야.
 
지금 우리는 main 브랜치에 0.11.0 릴리즈 버전이 있어. 이거 릴리즈 게이트 뚫은 버전이야. 한번 리펙토링을 하려고했었는데 엄두가 안나서 못한 코드야. 어떤 파일은 4천라인가까이 되었던것 같다.
 
이번에 v2-only에 acp를 재구현하는 것은 다시 설계해서 리포 구조를 신경써서 가는거야. 왜냐면 이 프로젝트가 entwurf v2는 사실상 '어댑터'를 하고 그 위에는 오케스트레이터 로직도 붙을 수 있는 core로 바라보고 있어. 지금 pi-shell-acp 0.11.0은 그냥 pi 확장도구야.
 
지금 v2-only로 가면서 나는 pi는 나의 4번째 하네스이자 특별한 녀석즈음으로 생각하고 있어. 이 정신은 우리 지금 브랜치의 핵심이야. 나는 이 틀을 다시 바꾸고 싶지 않아.
 
그래서 v2-only에서 브랜치를 새로 만들어서 거기에 acp를 넣는 것은 네 번제 하네스인 pi를 위한 plugin정도로 생각하고 있어. 이 감각이 맞다고 봐. pi에서 동작하는 acp 오푸스는 entwurfv2로 동작할거거든.
 
작업 단계는 기계적인 옮김은 안할거라는거야. 클로드 acp 지원부터 할거야. codex는? 안할거야. pr 왔던것 있지? 기업용하네스 그걸 해줄거야. 즉, 이말은 클로드의 acp는 상징적인 것이니까 해야하고(언제 크레딧으로 바뀔지모름). 기업용하네스의 경우 부족하거나 어떤 이유든가 별로라서 pi로 묶고 싶은 케이스라면 acp로 해주는거야. 메이저 에이전트 도구는 사용자가 많으니까 퀄리티가 좋을거거든. 그대로 쓰는게 좋다고봐.
 
이에 대해서 좀 고민 같이 해줘.

③ ACP 클로드의 정체성

원칙은 분신 형제간에 차별이 없어야 한다는 명제를 지켜야돼. 방식은 entwurfv2는 소켓방식과 메일박스 방식을 둘다 지원하잖아.
 
pi-shell-acp/claude-opus 라면 pi 소켓이 있어. v1의 경우는 소켓으로 동작했지. pi 에서 동작하는 클로드 오푸스니까. v1 버전은 몇달전에 만들어서 사용해 왔으니까 동작하는것을 알거든. 아마 메일박스로도 받아낼수도 있을거야. 근데 여기서 중요한 것은 아래 경로야.
 
acp 클로드는 오버레이 아래에서 설정 파일을 받아. 메일박스가 없어야 하는게 맞다고봐. 오버레이 설정이 필요한 이유는 베이스라인테스트에서도 수도 없이 했지만 pi 네이티브 수준, 즉 힣의 드라이버 1개만 주겠다는거야. 그렇기 때문에 acp 오푸스가 어느면에서는 더 가볍지. 기본 웹검색안되고 기본도구만 딱 주었으니까.

overlay 실측 (메일박스 부재 = 사실)

~/.pi/agent/claude-config-overlay/
  cache, debug, skills, telemetry, .credentials.json → symlink ~/.claude/* (auth/공유 통과)
  projects/, sessions/, plugins/, .claude.json, settings.json → 로컬 격리(숨김)
  settings.json = { permissions.defaultMode: default, autoMemoryEnabled: false, hooks: {} }
  → hooks 비어있음 = meta-bridge hook 없음 = 메일박스 없음(by design)
  → 같은 minimal 설정이 기본도구만 = 가벼움