Pi 프로바이더

왜 목록에 있는가

Pi는 전용 코딩 에이전트가 아니라 범용 툴킷이며, 바로 그 점 때문에 계획되었습니다. 목록의 다른 CLI는 모두 이미 구현된 것과 비슷한 모양이라, 계약이 일반화되는지 아니면 한 계열에만 들어맞는지를 알려 주지 못합니다.

프로바이더는 지목할 CLI의 정체성이며, 그 CLI가 무엇을 위한 것인지는 그 CLI의 사정입니다. Command의 어휘가 코딩 에이전트로 만들어진 도구에서만 통한다면, 그것은 스스로 주장하는 그 추상화가 아닙니다.

알려진 것

존재한다는 것, 그리고 목록의 나머지와 모양이 다르다는 것입니다. 그것을 구동하는 일에 관해 여기서 확립된 것은 없습니다.

알려지지 않은 것

그것을 구동하는 일에 관한 전부입니다. 아직 조사되지 않았습니다.

커맨드 이름과 대화를 식별하는 방식.
어느 플래그가 이것을 터미널 UI가 아니라 제어 가능한 양방향 스트림으로 만드는지.
출력이 type 판별자를 가진 NDJSON인지. 그렇다면 EventParser가 그대로 동작합니다.
권한 어휘, 그리고 닫힌 PermissionMode 집합이 그것을 표기할 수 있는지.
auth와 mcp 서브커맨드가 있는지, 그리고 어떤 형태로인지.
범용 툴킷이 애초에 어댑터가 필요로 하는 세션 형태의 표면을 드러내는지 — 가장 먼저 확인해야 할 것이지만, 확인되지 않았습니다.

붙였을 때 기여할 것

주로 코딩 에이전트가 아닌 CLI는 이 계약이 일반화되는지에 대한 가장 혹독한 시험입니다. SpawnOptions는 특정 CLI가 아니라 이 라이브러리의 어휘로 말하고, Command는 의도로 말합니다 — 메시지, 모델, 권한 모드. 형태가 다른 CLI를 그 단어들로 변경 없이 구동할 수 있다면, 그것은 추상화가 실재한다는 강한 근거입니다.

구동할 수 없다면 그것이 더 값진 발견이며, 작업 순서가 그것을 드러냅니다.

CLI의 실제 동작에 맞춰 어댑터를 정확히 이식한다.
기존 계약을 우회해야 했던 모든 지점을 기록한다.
존재하는 구현들에서 공통 형태를 추출한다.
그 뒤에야 AbstractAdapter를 넓힌다.

다음으로 볼 것

프로바이더 작성하기 — CLI를 붙인다는 것이 무슨 일인지.
왜 ActiveCLI인가 — CLI마다 래퍼를 하나씩 두지 않고 추상 어댑터를 두는 이유.
로드맵 — 작업 순서상 이것의 위치.