# Codex Auth Spine Inventory

This is the keeper list for the vestigial Codex organ. Anything not justified
here is suspect until proven otherwise. The organ must stay honest: Epiphany is
a modified Codex-derived backend with a native CultCache/CultNet body, not a
clean-room client pretending to be Codex.

## Compliance Invariant

- Keep Codex-compatible auth identity anchored in vendored Codex-derived
  machinery. Do not fully replace Codex auth with a lookalike native
  implementation unless OpenAI provides an explicit public path or permission
  for that use.
- It is fine to cut Codex apps, skills, marketplace, plugin UX, broad
  app-server workflow, and generic JSON control surfaces. Those are product and
  workflow organs, not subscription-auth legitimacy.
- The retained auth/model organ should be brutally thin, but it must be real:
  load/refresh credentials, preserve required client headers/identity,
  respect subscription limits, and call the allowed Codex/OpenAI model route.

## Live Spine

### Inputs

- User authentication material from Codex auth storage or an external auth
  provider.
- Model name and optional endpoint override from Epiphany-owned request/config
  surfaces.
- Per-turn model request data: prompt instructions, formatted input, tools,
  output schema, reasoning controls, service tier, and model metadata.
- Session identity: conversation/thread id, installation id, window id,
  session source, optional turn metadata, and optional parent/subagent headers.

### Durable Stores

- Codex auth storage under the configured Codex home. The legal/compliance
  authority should remain vendored Codex-derived auth machinery such as
  `vendor/codex/codex-rs/login/src/auth/manager.rs`, even when Epiphany wraps
  it in typed status documents.
- Auth token state in Codex-compatible auth records, including refreshable
  ChatGPT tokens and account metadata.
- No durable model/provider state is owned by the current OpenAI spine. The
  model string is request data; catalog/default selection must become a typed
  Epiphany document before it can be keeper machinery.

### Transformations

- `epiphany-openai-codex-spine` imports the narrow auth types and default-client
  construction it needs directly from vendored `codex-login`, without cloning
  env/file/keyring/token-refresh behavior or wrapping re-exports in another crate.
  Subscription credential authority remains in retained Codex-compatible
  machinery; Epiphany owns only the typed status/request/event/runtime surfaces
  around it.
- `epiphany-openai-codex-spine` converts `CodexAuth` directly into
  authorization/account headers, chooses the ChatGPT Codex backend or OpenAI API
  base URL from auth mode, builds a local serializable Responses request body,
  opens an HTTP/SSE stream through `codex-client`, and parses Responses frames
  into typed Epiphany stream events.
- `codex-login` remains in `vendor/codex` and should be treated as keeper
  auth machinery or the source for a thin vendored auth organ. Removing it from
  the native request graph may be an overcut if it makes Epiphany look like an
  impersonating client instead of a modified Codex backend.

### Outputs

- Bearer-authenticated OpenAI/ChatGPT-compatible model calls.
- Streaming model response events.
- No compaction/memory/realtime helper calls are part of this spine unless a
  typed Epiphany caller explicitly earns them later.
- No model catalog or model metadata store is keeper machinery yet.
- Auth and transport telemetry/errors needed to recover or report failure.

## Keep

- `codex-login`: keep as the legal authority for Codex-compatible subscription
  credentials. The Epiphany transport imports only its required auth surface.
- `codex-client`: keep only as a plain HTTP/SSE transport helper for now. It
  does not own Epiphany request shape, model policy, stream semantics, or durable
  state.

## Cut Or Seal

- Codex app-server routing is not part of auth/model transport. It can host
  compatibility wrappers while Aquarium/CLI still speak JSON-RPC, but it must
  not be the native Epiphany operator surface.
- Codex apps, skills, marketplace, plugin UX, and MCP OAuth handlers are not
  required for OpenAI subscription compatibility. MCP may survive as a separate
  CultNet adapter, not as a reason to keep the Codex app-server brain.
- `codex-core::client` helper calls for memories/realtime/compaction are
  suspicious unless Epiphany deliberately needs that OpenAI endpoint. Keep them
  sealed with the transport until the native adapter split can decide.
- `codex-api`, `codex-model-provider`, `codex-model-provider-info`,
  `codex-core::client`, and `models-manager` are no longer keeper request-path
  organs. `codex-login` is different: broad login UX can be cut, but the
  vendored Codex auth semantics should remain the anchor for subscription use.
  If a later model catalog is needed, it should be a typed Epiphany catalog
  document, not a revival of the old Codex provider stack.
- External bearer command auth and agent identity remain inside the retained
  vendored Codex auth organ. Epiphany should expose them only if a concrete
  typed runtime/status need appears; do not clone them into a second authority.

## Extract Target

Create an outside-vendor adapter with this shape:

```text
EpiphanyOpenAIAuthAdapter
  -> wrap retained Codex-compatible credential loading/refresh
  -> expose account/auth mode/model availability

EpiphanyOpenAIModelTransport
  -> accept typed Epiphany model-turn request
  -> call OpenAI Responses API through Codex-compatible auth
  -> emit typed stream events / receipts
```

The adapter may depend on retained `codex-login` auth machinery and
`codex-client` while the reliquary survives. It must not depend
on `codex-app-server`, `codex_message_processor`, plugin/app/skill/marketplace
modules, broad Codex provider/request construction, or Epiphany state
ownership.

## Next Cut

The first `epiphany-openai-adapter` crate boundary now exists as a native typed
surface:

- input: typed model-turn request plus adapter config
- output: typed stream events and terminal usage/error receipt
- current dependency: no Codex app-server and no Codex transport yet
- planned internal dependency: Codex auth/model transport only
- forbidden dependency: Codex app-server or Epiphany JSON-RPC routes

The first attempt to wire `codex-core` directly as a standalone path dependency
escaped the vendored workspace lock and hit transitive ICU/temporal dependency
skew. Do not paper over that with random version pins.

The first workspace-verified wrapper now exists as
`epiphany-openai-codex-spine`. It depends on the pure typed adapter plus the
keeper Codex auth types and projects `AuthManager` / `CodexAuth` into a typed
`EpiphanyOpenAiAdapterStatus`. `epiphany-codex-bridge` re-exports this spine so
the current app-server compatibility shell can compile it without making the
pure document crate depend on Codex.

The transport wrapper is now also in that spine. It maps typed
`EpiphanyOpenAiModelRequest` documents into a local serializable Responses
request body, resolves credentials through vendored `codex-login`, chooses the
ChatGPT/OpenAI base URL from auth mode, opens an HTTP Responses SSE stream with
`codex-client`, and converts stream deltas/completion into typed
`EpiphanyOpenAiStreamEvent` / `EpiphanyOpenAiModelReceipt` documents. It no
longer imports Codex `ResponsesApiRequest`, `ResponsesClient`,
`ResponseEvent`, provider config, model-provider, or broad app-server
workflow. Its narrow direct imports preserve Codex-compatible auth identity
without letting Codex own Epiphany request/state shape.

`schemas/cultnet/` contains publication schemas for OpenAI adapter status,
model request, stream event, and terminal receipt. Live providers own their
CultMesh/CultNet catalogs. The native runtime accepts the document types
registered by the actual CultCache runtime schema; there is no standalone
hello/catalog CLI or hand-maintained mutation-contract mirror.

The native runtime route is the operator and daemon edge.
`epiphany-openai-adapter` documents
derive CultCache `DatabaseEntry`, `epiphany-core::runtime_spine_cache`
registers OpenAI adapter status/request/stream-event/receipt documents, and the
outside-vendor `epiphany-openai-runtime` crate records typed OpenAI model-turn
requests, stream events, terminal receipts, runtime sessions, jobs, and job
results into the native runtime spine. Its `model-turn` command opens the
Codex-backed transport through the typed spine; its `smoke` command proves the
CultCache route without touching the network. This is the first native caller
for the advertised OpenAI CultNet contract.

Heartbeat/specialist launches use the atomic
`epiphany-core::prepare_runtime_spine_heartbeat_job` path. Initialization,
session admission, job creation, and launch receipts are one prepared CultCache
mutation rather than a caller-visible sequence.

The heartbeat launch plan is native as well:
`epiphany-core::plan_runtime_spine_heartbeat_launch` validates the launch
contract and active runtime-link conflicts, then returns the durable job binding
and runtime link. Vendored `CodexThread` is still a persistence adapter for the
compatibility route, not the owner of that state mechanics.

The Epiphany state-update contract and mutation law have also left vendored
Codex. `epiphany-core::EpiphanyStateUpdate` now owns the update document used
by the compatibility `thread/epiphany/update`, promotion, accept, and launch
paths. `epiphany-core::epiphany_state_update_validation_errors` and
`epiphany-core::apply_epiphany_state_update` own typed validation and mutation
application. `codex-core` re-exports the contract only as a compatibility
alias, and `CodexThread` now calls native state-update functions around its
remaining revision check, persistence validation, and rollout/session writeback.

The credential extraction overcut has been corrected. Codex file/keyring/auto
auth, env API key handling, ChatGPT token refresh, account metadata parsing,
and header-client setup remain in vendored `codex-login`. The redundant
Epiphany re-export crate is gone; the root workspace carries the Codex
`tokio-tungstenite` / `tungstenite` patches required for standalone builds.

The point is ownership: Epiphany calls a model adapter; it does not live inside
the Codex host brain.