Project Hive X

h2. 선행분석 결과

읽기 전용 조사만 수행했습니다. 코드 수정, 파일 생성/삭제/수정, Redmine 업데이트, 테스트 실행은 하지 않았습니다.

현재 0.142.2 번들 pin 및 최소 app-server 버전 gate는 반영되어 있습니다. Hive sensitive-file 정책은 resources/requirements.toml -> requirementsPolicyService -> appServerProcessConfig -> app-managed CODEX_HOME/config.toml 순서로 materialize되며, bundled remote-cache 실행에서는 permissionProfile=hive-sensitive가 supervisor에 전달됩니다.

h3. 확인된 갭

• live thread/start, turn/start에는 permissions: "hive-sensitive"가 송신되지만, thread/resume과 thread/fork에는 현재 permissions가 송신되지 않습니다.
• 0.142.2 ThreadStart/ThreadResume/ThreadFork/TurnStart params의 runtimeWorkspaceRoots가 Hive request payload에 없습니다.
• 0.142.2 start/resume/fork response 및 thread/settings/updated의 activePermissionProfile을 runtime snapshot/UI state에 보존하지 않습니다.
• scripts/fixtures/hive-app-server-contract.json의 필수 subset에도 permissions/runtimeWorkspaceRoots가 빠져 있어 schema gate가 이 갭을 잡지 못합니다.

h3. 수정 범위

• appServerSupervisor의 live request 생성 함수에 runtimeWorkspaceRoots를 추가합니다.
• thread/resume, thread/fork에도 bundled named profile 경로에서는 permissions: "hive-sensitive"를 송신하도록 연결합니다.
• start/resume/fork response의 activePermissionProfile과 runtimeWorkspaceRoots를 normalize해 runtime state에 보존합니다.
• thread/settings/updated에서 threadSettings.activePermissionProfile을 projection하도록 이벤트 타입/store 처리를 추가합니다.
• app-server-supervisor-live, runtime projection/store behavior test와 contract fixture를 보강합니다.

h3. 볼륨 판단

#526 한 일감 내 처리 가능하다고 판단합니다. 단, permissionProfile/list UI, clientUserMessageId, environments, selectedCapabilityRoots 제품화는 후속 일감으로 분리하는 것이 좋습니다.

h3. 검증 계획

• vitest run src/renderer/app-server-supervisor-live.behavior.test.ts
• vitest run src/renderer/runtime-event-projection.behavior.test.ts src/renderer/runtime-store.behavior.test.ts
• vitest run electron/appServerProcessFactory.behavior.test.ts electron/enterprisePolicyValidation.behavior.test.ts
• npm run validate:codex-app-server-schema
• 가능 시 0.142.2 binary/bundle 기반 sensitive-policy/app-server smoke

h2. Codex app reference 기준 진행방향 업데이트

사용자가 “Hive 앱은 정식 레퍼런스로 Codex app을 따르며, 가능한 동일한 동작방식 및 표시 형태를 따라야 한다”고 방향을 확정했습니다.

공통 원칙:

• wire/protocol compatibility는 target Codex CLI 0.142.2 generated TS/schema를 기준으로 한다.
• UX, 표시 형태, suppress 여부, 사용자-facing wording은 Codex app reference를 먼저 관찰하고 가능한 동일하게 맞춘다.
• 현재 설치된 /Applications/Codex.app/Contents/Resources/codex는 codex-cli 0.142.0이므로, 0.142.2 신규 필드는 0.142.2 schema로 검증하고 표시 정책은 관찰 가능한 Codex app 동작을 우선한다.
• Codex app에서 보이지 않거나 확인 불가한 surface는 Hive가 임의 UI를 만들지 말고 protocol/state/diagnostics 중심으로 처리한다.
• 단, Hive Gateway credential, enterprise policy, sensitive-file warning/redaction처럼 보안/운영 경계는 Codex app parity보다 엄격해질 수 있다.

h3. #526 진행방향

권한 프로파일과 workspace roots는 Hive식 새 UI를 만들기보다 Codex app의 thread/session 권한 상태 반영 방식을 기준으로 맞춥니다. permissions, activePermissionProfile, runtimeWorkspaceRoots는 0.142.2 wire field 그대로 송수신/보존하고, Codex app이 별도 사용자 표시를 하지 않는다면 Hive도 renderer-visible UI를 늘리지 않고 snapshot/state/diagnostics 중심으로 둡니다. hive-sensitive는 Hive 보안 정책상 유지하되, 사용자가 보는 권한 흐름은 Codex app과 최대한 동일하게 보이도록 합니다.